geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject 1.2 Release Plan
Date Wed, 08 Nov 2006 19:54:53 GMT
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

Mime
View raw message