On 11/28/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > 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.
A Test Build, which is what we issue when we build a 1.2.8, for example, is not a release either. It's exactly what it says it is, and it doesn't claim to be anything more. It might be promoted, or it might fall by the wayside, but that's not decided until later. A Release Candidate is already claiming to be better than a Beta, in this case without being tested by anyone other than the builder. 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. I disagree. For one thing, if there were packaging errors, could it rightfully be called a Release Candidate? And as for "using up" .z digits, I really don't think that matters - unless, of course, you are dead set on the first GA being exactly 1.0.0. But why? We got into this, in part, because we (including you ;) liked the way Tomcat did things, and they don't work that way. I don't think it's confusing to issue multiple Test Builds when people understand how we work. What _is_ confusing is to reintroduce the notion of a Release Candidate a year after we got rid of it. 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. Not this one. ;-) -- Martin Cooper Craig > >
