On 11/28/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > 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. ;-)
I've been doing it the RC way in commons because thats what their release notes say to do. However, IMO the Struts (or httpd) way is better because once you've created the distros thats it, whatever the "label" applied after. I nearly cocked up the Validator 1.2.0 release recently after RC4 was voted on because I initially forgot to switch back to JDK 1.3 when building the actual release. Struts 1.2.8 was much easier because by the time the voted passed all that was left was a few minor admin things that even if they get messed up, can be corrected and don't affect the "quality" of the distro. Maybe if you want a 1.0.0 GA quality Shale, the best thing to do would start at version 0.9.0? Niall > -- > Martin Cooper > > > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
