Re: [rt-pmc] Vert.x 2.1.0 release

[Wayne Beaton <wayne@xxxxxxxxxxx>]

I also would prefer to change the process if that's the right thing to do.

The current process requires a minimum of one week of community review and IP Log approval for every release. We have some flexibility with regard to review materials.

Can we reasonably assume that the last week before any release will be entirely testing and bugfix work (i.e. no new features) ?

Do releases have anything like a plan? At the beginning of a release cycle, is there any conscious "this is what we're working on for the next four weeks"?

I see no release notes, readmes, or release-specific documentation of any kind in bintray or the project website? Do I just need to look harder, or is this information captured somewhere else?

Wayne

On 03/12/2014 05:46 PM, Ian Bull wrote:

We might, for example consider a model where Vert.x produces an official release once a year, and produces milestones on a six week cycle leading up to that release. Many (perhaps even most) projects do this today. You might consider pushing out some service releases after the main release, but--again--that's up to you.
     

Although we should also make sure the process is in the spirit of what the community wants too. If the community is told that the 'release' is out-of-date and the milestone is what you should be using, then an annual release (just to satisfy the EDP) is not the answer.

Software delivery has certainly changed a lot since I started working with Eclipse. Firefox seems to 'release' a (major?) update every two months, and in the past week that I've tried the Atom editor, I've already had 3 updates. I don't know if Vert.x has a maintenance stream and if each 'release' results is subsequent maintenance releases too.

Wayne, if a project wanted to cut a release on a monthly schedule (for example), what challenges would you (the EF / EMO) face? Is it IP vetting time? Approval time? Technical challenges? 

I imagine we'll be discussing release schedules during the Planning Council meeting on Sunday. Whenever this subject comes up, we always go back and forth between the #1 technical problems the project would face, #2 the challenges the users would face and #3 the EDP requirements. Maybe we need to separate these concerns, and let the projects worry about #1 and #2.

Cheers,

Ian

--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects