THIS IS A DRAFT
Core documents
We follow the [http://www.apache.org/foundation/voting.html Apache Voting Procedure] with the below modifications. In addition, the PMC has defined as policy that the [http://cvs.apache.org/viewcvs.cgi/spamassassin/trunk/build/README?root=Apache-SVN&view=markup build/README release procedure] must be followed when making a release.
Who can make a release?
Any member of the Apache SpamAssassin project (committers) can make a release designated with Apache.
Who is in charge of a release?
The release is coordinated by the Release Manager (RM). Since this job requires coordination of the development community (and access to SVN), only committers to the project can be RM. However, there is no set RM. Any committer may perform a release at any time. In order to facilitate communication, it is deemed polite to alert the community with your planned release schedule before executing the release. A release should only be made when there is a plan to publicly release it. (A release should not be made only for private distribution. A private release is more suitable for that.)
Who may make a good candidate for an RM?
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. In general, our experience has shown that a well-coordinated release fares better than non-coordinated releases.
When do I know if it is a good time to release?
It is our convention to indicate blocking issues in Bugzilla with the severity set to critical. A showstopper entry does not automatically imply that a release cannot be made. As the RM has final authority on what makes it into a release, they can choose to ignore the entries.
An item being denoted as critical indicates that the group has come to a consensus that no further releases can be made until the entry is resolved.
In addition, pre-releases may be more acceptable to the community with one or more showstopper bugs.
What power does the RM yield?
Regarding when a release is made, the RM is the unquestioned authority. No one can contest what makes it into the release so long as the release procedure defined in build/README has been followed. The community will judge the release's quality after it has been issued, but the community can not force the RM to hold off a release for a feature. Remember that this document is only a guideline to the community and future RMs - each RM may run a release in a slightly different way.
How can an RM be confident in a release?
The RM must follow the release procedure defined in build/README. This is project policy set by the PMC and is not optional. Once the tree has been suitably tested by the RM and any other interested parties and the required procedure (including three +1 votes), they should "roll" the release out.
What can I call this release?
There are three names for releases approved by the PMC:
- pre-releases (alpha)
- release candidates (beta)
- full release (general availability)
The type of release needs to be chosen before beginning the release procedure since it is part of the tagging of the tree, etc.
Pre-release indicates that the release is not meant for mainstream usage or may have serious problems that prohibits its use. Release candidates are expected to work and perform basic tasks with no serious issues or work remaining (like optimizing the scores). However, there may be problems with this release that prohibit its widespread adoption. Full releases are recommended for production usage.
Who can vote?
Non-committers may cast a vote for a release's quality. In fact, this is extremely encouraged as it provides much-needed feedback to the community about the release's quality. However, only binding votes casted by committers count towards the designation. Note that no one may veto a release. The PMC or the release manager may revoke all votes on a release if a new major problem is discovered prior to publication of a release and request a revote. However, once there are greater than 3 positive votes, the release may be made at any time. In addition, the RM may decide against making a release even if the required votes have been made.
Oops. We found a problem
If the "point of no return" described in the build/README has not been reached, then the release may be abandoned and begun again.
If the "point of no return" has been reached, but the release has not been made public via tarballs, then the release may be abandoned, but the version number is considered burned.
If the release has been made public and the problem is so severe that the release absolutely should not have been made, then the tarballs may be renamed to "-dontuse" and a new announcement may be sent at the discretion of the release manager.