On 2/23/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> Personally, I think it gets silly to have to vote each time.
Well, we really shouldn't cast a binding vote on a release until we
put into production ourselves. ("Eat our own dog food.") Since this is
a new roll, we have to unroll it, put it up, and run the binary
through its paces. just to be certain all the bits are there.
After doing that, voting is the least of it :)
One way to streamline the process is to using numbered milestones
rather than beta's and RCs. Under this scheme, this distribution would
be Roller 2.1.4. We start by releasing it as an Alpha, and then decide
to vote it up to a Beta or GA.
The benefit is that we don't have to touch the distribution pr
repository, even just to rename things. We can tag the repository once
as _2_1_4 and roll that milestone once and for all. If it doesn't make
the grade, we just go onto the next milestone. Right now, if we decide
RC5 is ready for primetime, the same set of bits might have two names
"RC5" and "2.1".
Another benefit is that we can also downgrade a release. If we later
find a security issue, we can bring out a new milestone and change the
quality of "2.1.4" to beta.
This is the scheme that Apache HTTP, Tomcat, Struts, and others use.
Incidentally, it's a good practice to record every PMC vote in a
STATUS file. Here's the one we use with iBATIS.
* http://svn.apache.org/repos/asf/ibatis/trunk/STATUS.txt
-Ted..
