Thanks for taking the time to explain in detail. The bit that was really confusing me was the idea of jumping from 1.1 to 1.2.1.
I think there's got to be a 1.2.0, but I also think that it should be a stable, production quality release. People will infer that from the number, whether we like it or not. >From that, it would seem that there's still a requirement for betas/rcs before a minor version increment. Steve > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: August 10, 2003 9:43 AM > To: Struts Developers List > Subject: Re: When is the next release? > > > AFAIK, the consensus is that our releases should follow the same general > process used by the Jakarta Commons and the Apache HTTP Server project. > > So, for reference, I'm following > > http://httpd.apache.org/dev/release.html > > and > > http://jakarta.apache.org/commons/releases/ > > but observing the HTTPD numbering system. > > Right now, I intend to post a Release Plan for majority approval, either > late tonight or early tomorrow. This Plan would include when we plan to > roll the initial Alpha release. (I may even decided just to roll a > release and post that along with the Plan.) We'd then vote whether to > upgrade 1.2.1 from Alpha to Beta or General Availability (GA). > > Since there are any burning reasons to ship this instantly, I'm taking > it as a foregone conclusion that this first roll will be at least a > Beta. I'm confident that there are not any "serious problems that > prohibits its use", so I don't believe it will not remain an Alpha. But, > I do suspect that there may be "problems with this release that prohibit > its widespread adoption" -- even if it simply documenting "what to do > now that X is deprecated". So, I was calling it a Beta release. > > Once we have cleaned up the 1.2.1 roll (which I wager will only be a > Beta), we can roll 1.2.2. Hopefully, the 1.2.2 release will merit the > General Availability stamp. Of course, nobody knows until the vote. > > Heretofore, we have rolled several version of the same "release" and > then suffixed them B1, B2, and so forth. Moving forward (as I understand > it), we of these releases get their own integer. If the release does not > make it to GA, it dies on the vine, we and go onto the next number. > > In practice, you often get a odd/even pattern, where the odd was the > "beta" or "development" version and even is the stable release. Some > communities, like Linux, Perl, and Emacs, codify this pattern. When the > odd-beta is sufficiently patched to make it release-worthy, they roll it > over to the next even number and release that for general availability > > AFAIK, we're not enforcing the odd/even pattern or a formal "patch > level". So, if we roll 1.2.2 and it fails to get the votes for a GA, > we'd go on to 1.2.3, and if that passes, it becomes the next "stable" > release, odd or not. > > Of course, it would even be possible for 1.2.1 to pass a GA vote, if > someone called for one. Personally, I think that unlikely, if only for > documentation issues. But, others could out-vote me if the consensus > feels differently. > > The core idea is that when any of us feel brave enough to roll a > release, we can tag CVS with the next integer, and have at it. The > instant we tag and roll it, it's automatically an Alpha. To upgrade the > status from Alpha to Beta, or from Alpha to GA, we need a Majority Vote > of the Committers (At least three committers have voted positively for a > status and that there were more positive than negative votes (three is > our working quorum for a binding vote)). > > To prevent any confusion with the CVS tags and so forth, the releases > are immutable. Once it's rolled, it's rolled. If there's an issue that > keeps a release from being upgraded, you either patch it, or tag and > roll another release. > > To ensure that two us don't start rolling a release at once, it's > prudent to announce your intentions first. Depending on how formal you > want to be, that announcement might be dubbed a "Release Plan". But the > only thing that matters is whether the release you roll passes a > Majority Vote to move it from Alpha to Beta or GA. > > At least that's how I understand it =:0) > > Since this release is not backwardly compatible with 1.1.x, having > removed all those deprecations, we are moving to the 1.2.x release > series. Until something compels us to go on to the 1.3.x series, we can > make be as many "General Available" releases in this series as we need. > > The current GA for Tomcat 4.1, for example, is now 4.1.27. I'm not sure, > but I believe the GA release before .27 was .24: .25 and .26 didn't make > the GA cut. > > One point I'm fuzzy on is whether we should do 1.2.0 or 1.2.1 first. I > had thought it would be 1.2.0, but Martin and Craig seem to be saying we > should start with 1.2.1. Being a geek, my natural inclination was to > start with zero. =:0) > > -Ted. > > > Steve Raeburn wrote: > > >>-----Original Message----- > >>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > >>Sent: August 9, 2003 8:57 PM > >>To: Struts Developers List > >>Subject: Re: When is the next release? > >> > >>That was my understanding as well -- we agreed to switch to the x.y.z > >>style that Apache HTTPD and Tomcat are using, where you post > the bits and > >>then call for a vote on stability (alpha/beta/general > availability). It's > >>perfectly reasonable to have a series of "general availability" releases > >>with new features in the 1.2.x series, as long as we continue > to maintain > >>backwards compatibility within it. > >> > >>Therefore the first release would be 1.2.1 and we'd keep going > from there. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
