On 2/10/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
...The webwork/struts 2 guys have a nice write up for their release procedure [1]. Can one of our mentors tell more if [1] is too high ceremonial, or just right?..
...
[1] http://cwiki.apache.org/WW/creating-and-signing-a-distribution.html
That page describes many details that are specific to webwork/struts2, but in general the important steps are (other mentors, feel free to correct or expand of course): 1) Someone prepares the release artifacts (tar.gz and/or zip archives, etc) in a "release scratchpad area" (usually on people.apache.org) and posts a [VOTE] message to have them accepted. This message includes the md5 digests of the artifacts, to avoid any confusion if they're updated later, as happens when adjustments are needed. 2) PMC members download the artifacts, check their md5, unpack them and check the contents (functional checks, automated tests, legal aspects, etc). 3) PMC members vote to accept the release, indicating specific reasons if they don't accept it. I find it good at this stage to indicate what you've checked when voting +1, as sometimes one doesn't have the time or resources to check all aspects of the release. If the release is not accepted by a PMC member, the vote restarts after correcting the artifacts and posting the new md5 digests. 4) Once the vote passes (according to the ASF's voting rules, [2]), the release manager moves the files to the final distribution destination, and makes the necessary announcements, usually after waiting for the artifacts to be propagated to all mirrors. Hope this helps - the main points are that PMC members vote on the actual binaries that are going to be distributed, based on these file's md5 digests. Code repositories should also be tagged when cutting releases, of course, but it's the md5 digests which are binding. Although I have described the process in detail, there's not much bureaucracy involved. It's just a logical process that enables the PMC to collectively take responsibility for the releases, so that the release managers don't have to bear the burden alone. -Bertrand See also: http://www.apache.org/dev/release.html http://incubator.apache.org/guides/releasemanagement.html#best-practice [2] http://www.apache.org/foundation/voting.html
