On Sun, 10 Aug 2003, Steve Raeburn wrote: > Date: Sun, 10 Aug 2003 12:38:06 -0700 > From: Steve Raeburn <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: RE: When is the next release? > > 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. >
There were only a very small number of people in Tomcat that didn't get it. And now we'll have both Tomcat and Apache HTTPD to point at for how the process works, so it shouldn't take people very long. > >From that, it would seem that there's still a requirement for betas/rcs > before a minor version increment. > Actually, the revised approach we are discussing totally *eliminates* any predeciding what quality we think a release should be branded with. That is discovered after the fact. The only gating factors for a new release should be: * Whatever changes being factored in are at a stable point * Documentation and release notes are up to date. If we target roughly one 1.2.x release per month, we'll be doing very well. > Steve Craig > > > > -----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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
