Apache HTTP Server Release Guidelines - The Apache HTTP Server Project

This document describes the general release policies used by the Apache HTTP Server Project to create releases of httpd-2.4 (the current Apache 2.x branch). Aside from the voting guidelines, this policy may be adjusted by the Release Manager.
With the introduction of Apache 2.1, the Apache httpd project has adopted an odd-even release strategy, where development happens with alpha and beta releases assigned an odd-numbered minor version, and its general availability (stable) release is designed with the subsequent even-numbered minor version. E.g. 2.1.0-alpha through 2.1.6-alpha were followed by 2.1.7-beta through 2.1.9 beta, and cumulated in the 2.2.0 general availability release.
Technically, anyone can make a release of the source code due to the Apache Software License. However, only members of the Apache HTTP Server Project (committers) can make a release designated as Apache HTTP Server (httpd). Other people must call their release something other than "Apache" unless they obtain written permission from the Apache Software Foundation.
Following our official release policies, we will only accept release binaries from members of the Apache HTTP Server Project for inclusion on our website. This ensures that our binaries can be supported by members of the project. Other people are free to make binaries, but we will not post them on our website.
The release is coordinated by a Release Manager (hereafter, abbreviated as RM). Since this job requires trust, coordination of the development community, and access to subversion, only committers to the project can be RM. However, there is no set RM, and more than one RM can be active at a time. Any committer may create a release candidate, provided that it is based on a releasable (non-vetoed) tag of our current subversion repository corresponding to the target version number. In order to facilitate communication, it is deemed nice to alert the community to your planned release schedule before creating the release candidate, since some other folks may be on the verge of committing an important change (or backing out an error). A release candidate should only be made when there is an intention to propose it for a vote on public release. There are no "private" releases at Apache.
Someone with lots of time to kill. Being an RM is a very important job in our community because it takes a fair amount of time to produce a stable release. If you feel lucky, a release could be distributed without testing, but our experience has shown that this leads to a higher number of dud releases. In general, our experience has shown that a well-coordinated release fares better than non-coordinated releases. In all cases, three +1 votes, and more +1 than -1 votes from PMC members are required for a release candidate to be designated as a release.
Generally speaking, when some useful changes have been applied since the last release and there are no showstoppers left to be resolved. It is our convention to indicate showstoppers in the STATUS file in the repository. A showstopper entry does not imply that a release cannot be made -- it is more of an indication of current project consensus and a reminder of what fixes are on the critical path. Each RM gets to choose when to cut a release candidate based on the current content of subversion. The entire PMC gets to decide whether or not that candidate deserves to be released.
An item being denoted in STATUS as a showstopper indicates that someone believes the issue must be resolved before the next release, and the RM is going to hold off until it is resolved or moved out of the showstopper category. These items may be bugs, outstanding vetos that have not yet been resolved, or enhancements that must make it into the release. Note that the RM may also add showstopper entries to indicate what issues must be resolved before they personally are willing to cut a release candidate, though they cannot prevent others from taking on the RM job and proposing a release candidate of their own.
The only power held by the RM is the right to determine when the current content of subversion is worth their own effort in cutting a release candidate. The only thing the RM has authority over is the building of a source package, based on the contents of our subversion, that can then be put up for vote. They can decide what snapshot revision to tag for a candidate. They can decide to branch early and build candidates based on the branch rather than a more active development tree, but they cannot prevent others from working on that branch as well. They can also decide not to build anything at all. They can do all sorts of organizational support, advocacy, pleading, or whatever in order to encourage the rest of the project committers to apply changes, test the candidate, vote for things under issue, etc.
The RM is not a dictator (benevolent or not). They do not have the right to pick apart or select any variation of the product they might like to release: it has to be a specific tag or revision (moment in time) that is present in our subversion and applicable to the version number targeted for the release. If there is something they don't like in the tree, then they have the same right as other PMC members to change or veto that code first, make the change to subversion, and then build the release candidate. Likewise, the RM cannot include in the candidate any change that has been vetoed by others, and their candidate cannot be released if it contains any changes that have been vetoed since it was built. The RM has the right to kill their own candidate if they learn something during the release process that they think, for whatever reason, causes the build to be unreleasable. But the RM can't stop anyone else on the PMC from taking the same candidate and calling for its release under their own management as RM.
The RM may perform sanity checks on release candidates. One highly recommended suggestion is to run the httpd-test suite against the can