We can have as many phases as we like. We often vote a distribution as "beta" first, and announce it to the use list, and then depending on that experience, vote again and reclassify the "beta" to "GA".
A key idea is that we should be releasing the same set of bits that we tested, without change. Aside from the people here, our only other testing group are subscribers to the Struts user mailing list. We need to release a set of bits to that group, let everyone test it, and if the bits are joyful, declare them GA. The quality we assign to a release should not be a matter of personal belief, it should be determined by what we have found through actual experience in the field. Of course, we could do something like distribute a set of bits tagged as a "release candidate", and if the RC is found joyful, we could copy or rename the tag, build a distribution from the same tag, and call it the GA. But, of course, those would not be the same bits, only very similar bits. Even if we assume that we can build an equivalent distribution from the same tag under a new name, all the helpful souls who have been using these bits in production would have to change JARs again. An approach like this simply creates more work for everyone, without producing a single tangible benefit. (How rude!) If later we find a problem with a release, we should also downgrade it from GA to beta, or Alpha. Actually, we should do this with the releases prior to 2.0.9, since I don't think any of us would recommend that those distributions be used in production. -Ted. On 10/2/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote: > It is a pretty interesting process, but probably the vote call should be > changed. There will be a "two-phase" vote, where: > - in the first phase, we vote if we want the test build released (without > mentioning the quality); > - in the second phase we vote the quality. > Thoughts? > > Antonio > -- HTH, Ted <http://www.husted.com/ted/blog/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
