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
[EMAIL PROTECTED]
