geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: 1.2 Release Plan
Date Fri, 10 Nov 2006 13:47:08 GMT
Overall I like the plan.  It is a good division.  I assume that as  
new bugs are cropped up we would make the decision on whether they  
are a show stoper or not.  For the most part we should have addressed  
them earlier if IIUC.

On Nov 8, 2006, at 2:54 PM, Dain Sundstrom wrote:

> For the 1.2 release I'd like to try something different.   
> Historically, we complete the TCK work, spend several weeks working  
> on Fit and Finish and then spend another several weeks voting.  The  
> voting period tends to take a long time because we start voting  
> before there is community consensus that the code it good enough to  
> be released.  Even after that, we can still have to delay the  
> release further due to last minute legal issues such as the Sun  
> schema issue last time.
>
> This time I'd like split the process into a Development Phase and a  
> Release Phase with a clear, voted upon, transition between the two.
>
> The Development Phase includes implementations of all features,  
> improvements, and bug fixes, the TCK work, and the Fit and Finish.   
> We stay in this phase until we have the software ready to be  
> released to users.  The end of this phase is signified by a vote to  
> move the software to the release process.  Specifically, a +1 vote  
> would mean that you are comfortable with the features,  
> improvements, performance, quality and the known bugs in the  
> server, and if we were able to release the software that day, you  
> would.  After a super majority vote, we move to the release phase.   
> Of course, we can't release until we review the software for legal  
> issues, create the final bundles, and TCK test it on last time, and  
> that is why we have a separate release phase.
>
> The Release Phase begins by cutting a branch and publishing a rc1  
> binary, and the development trunk switched to the next release.   
> Then we start the legal review, and work with SNAPSHOT dependency  
> projects such as TranQL and OpenEJB to create a joint final  
> release.  When we believe we have addressed all out standing  
> issues, we create a new release candidate and vote for final  
> release.  One thing to note, is that at no time in this process  
> should be be substantially changing the source code.  The community  
> has already decided that they are comfortable with the features,  
> improvements, performance, quality and known bugs.  Of course  
> exceptions can be made, but they should be done with caution and  
> only upon a successful vote.
>
> I know there are some minor points that could be picked at in this  
> plan, but what do you think about it over all?
>
> -dain
>

Matt Hogstrom
matt@hogstrom.org




Mime
View raw message