Miscellaneous comments interspersed. On Sun, 10 Aug 2003, Ted Husted wrote:
> Date: Sun, 10 Aug 2003 12:43:16 -0400 > From: Ted Husted <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: Struts Developers List <[EMAIL PROTECTED]> > 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). > The way Tomcat does it, you don't even claim "alpha" status until after a vote. They do a limited announcement of "here's the bits, try 'em out" to just tomcat-dev and tomcat-user (essentially, it is a "test" release), then hold the vote. I think there's merit in this approach -- stability, like beauty, is in the eye of the beholder :-). Also, we shouldn't be shy about just abandoning a release if it turns out to have fatal bugs -- just fix them, and get ready for the next. > 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. > It depends partly, of course, on what features we decide to add in each release. > 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 > Tomcat's 4.1 experience was that only every sixth release or so was voted GA, at least for the first several. Now that they're up to 4.1.27, and the number of changes is much more limited (new development is happening in the 5.0.x series), GA things will probably happen a lot closer together. > 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. > Yep. Patterns don't really matter. > 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. > I think it's unlikely to pass a GA vote, simply because ripping out all the deprecated stuff is a fairly major amount of surgery, and we might have missed something. But we'll see. > 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. > Absolutely. One missing detail in the plan, though, is whether we branch on each 1.2.x release. Tomcat doesn't and I don't see a reason to since we would probably never go back and try a 1.2.5.1 release to fix something in 1.2.5. Another thing Remy does for Tomcat (which I *really* appreciate) is keeps a running change log (summary, not detailed) in the release notes for each version. That way, everyone can get a quick summary of what's changed. I'd like this kind of thing to be part of the release manager's responsibilities. > 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) > Sounds good to me. > 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. Yep -- the ones that did were 4.1.6, 4.1.12, 4.1.18, and 4.1.24. The fact that it was every six is mostly coincidence and was caused by a large amount of refactoring work going on. > > 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) > I'm a zero-relative guy at heart :-). My only concern is that people will assume 1.2.0 really means 1.2, but I'd be happy with either 1.2.0 or 1.2.1. > -Ted. > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
