How we do a release at the ASF

10 February 2007 asf opensource

As a mentor for the Wicket project, I've tried to explain how we do releases at the ASF.

This is no official statement! It's only my view of it, feel free to comment of course. I've tried to reduce the explanation to the important points: basically, PMC members vote to accept the binary files that are going to be released, based on these file's md5 digests.

So, in general (and IMHO) the important steps are:

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 the dev list 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.

PMC members download the artifacts, check their md5, unpack them and check the contents (functional checks, automated tests, legal aspects, etc).
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.

Once the vote passes (according to the ASF's voting rules, [1]), 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.

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 actual distribution files (via their 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.