On 11/28/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 11/27/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > I agree that release candidates can be helpful with checking packaging > > errors (and testing against TCK which is not an issue in this case.) > > That's true, Sean, but what you may not know is that over a year ago, > we had a very long discussion on dev@ about the release process. In > the end, we decided that Apache Struts would *not* issue distributions > that were tagged with arbitrary qualifiers like "beta" or "release > candidate". Each and every non-nightly distribution would be a > milestone with it's own unique version number expressed as three > integers (major.minor.milestone). Witness the Struts 1.2.x series for > this process in action. > > We worked very hard to educate people as to the "milestone-only" > release scheme, and I am concerned that calling anything a "release > candidate" again will only cause confusion. > > It is my feeling that the so-called 1.0.0-rc1 should be tagged as the > 1.0.0 distribution, and the subsequent distribution should be 1.0.1. > If 1.0.1 becomes a GA release, that would be great. If it doesn't, > then 1.0.2 can be next up to bat.
Your description of the x.y.z release approach that we came to agreement on is accurate ... but that approach doesn't say anything about "I'm about to post this as release x.y.z ... does it look ok to everyone?". A release candidate is not a release ... it's a staged package that (if there are no problems) can become the release. It's pointless to use up .z digits for simple things like packaging errors (which were discovered in this case, and would have meant immediately issuing a 1.0.1 to replace them). That's much more confusing to the world than posting a release candidate to be tested -- and yes, that should have only been mentioned on the dev list. You will find many of the Jakarta Commons package developers (including some who use the x.y.z approach that we do) doing exactly the same thing, for exactly the same reason. Craig
