Any updates on 1.2.x?
Another matter required my undivided attention last week, and so I haven't been able to work on this since my last post.
IMHO, before we start on the 1.2.x series, we do need to audit the outstanding LATER and REMIND tickets. A good number of these were created during the 1.0 -> 1.1 era, saying that we would revisit them post 1.1. So, if it's post 1.1, we should honor our obligation, and revisit these tickets. I'm sure that nearly all of them are obsolete, but, IMHO, we do need to practice due diligence and dispose of them.
Reviewing these tickets is not something that has to be done by a Committer. Any knowledgeable member of the Community can review these tickets and dispose of any that are obsolete. All changes are sent to the list, and so we have all have an opportunity to override any change.
A Committer does need to apply any patches to CVS, but, again, any member of the community can review a ticket with a patch to see if its obsolete or whether the patch "works for me".
I will be working through these myself, but if anyone one is willing to make it a joint effort, please feel free to jump in.
Also, a release is a majority vote. While I feel that this needs to be done, other Committers may disagree. If someone else wants to do the work of making a 1.2.x release without the Bugzilla audit, you won't hurt my feelings. =:0) --- It's not about what any one of us think, it's about consensus and community. I feel that resolving these tickets is an important part of community-building, but that's just me =:0)
-Ted.
Ted Husted wrote:
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]
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
