1.2 Release Plan

[Dain Sundstrom <da...@iq80.com>]

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

Re: 1.2 Release Plan

[Matt Hogstrom <ma...@hogstrom.org>]

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