hopefully other folks with release management experience will speak up too.
On 27 Nov 2003, at 16:44, Oliver Zeigermann wrote:
Christopher Lenz wrote:Oliver Zeigermann wrote:Hi, folks! Seems to be time for the vote upon the 2.0 release!This should be "the 2.0 release plan". Of course, each release (alpha, beta, whatever) needs a separate vote. A must-read (IMHO) for a release manager is Robert's great guidelines for the Jakarta-Commons project:
This is an *informal* vote, just to see interests are really aligned. Before a final release there will be a formal vote. I see no need for a vote of an alpha or beta, but we can have one, no problem with me.
the procedure you're describing is what i'd call a release plan. i always create a release plan and have a vote but (as you say) it's to ensure that there's nothing i haven't forgotten and to make sure everything's aligned (as you say).
there's now a new url that's the must-have reading for release managers: http://nagoya.apache.org/wiki/apachewiki.cgi?ReleaseManager. it links to how-to-release pages around apache. it's not perfect (please feel free to improve it) but it's be best we've got. the following url is also worth browsing (http://jakarta.apache.org/site/guidelines.html). it describes our rules (here at jakarta).
apache releases come in various flavours: unstable (milestones, alphas, betas etc) and stable (full releases). all ASF releases (whether unstable or stable) require a successful release vote and approval from the appropriate pmc. (i think that christopher - hopefully, he'll correct me if i've made a mistake - was saying that a release vote is required whether the release is alpha, beta or full rather than suggesting that you create an alpha.)
i would strongly suggest that you add the creation of at least one release candidate to the plan. a release candidate has a lot of advantages: not only does it allow a wider range of users to test it (a good way to save blushes) but it can be announced in the news section of the jakarta site (a good way to drum up interest) and you get a chance to try out the release procedure (before the real thing).
it's very important to remember that the final approval for the full release needs to come from jakarta pmc. (this is for legal reasons.) the current procedure is to copy the pmc with final result of the final release vote and then wait a day or two too allow the pmc time to veto the release. (please subscribe to general at jakarta since this process may change in the future.)
one thing that you should decide is whether you're going to do everything (including the upload) or whether you'd prefer to manage the release but have someone else perform the release build and upload. if you do want to do everything, you'd be well advised to read carefully the links about signing releases and then install and configure a signing tool (for example http://www.gnupg.org).
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
