Core documents
We follow the Apache Voting Procedure with the below modifications. In addition, the PMC has defined as policy that the build/README release procedure must be followed when making a release (it defines the SpamAssassin release process in great detail).
Who can make a release?
Any committer on the Apache SpamAssassin project 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 snapshot is more suitable for that.)
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. However, issues that concerns a rule, even if the severity is critical or higher, is NOT a blocker to a code release because rules are released separately.
Pre-releases may be still be issued with one or more showstopper bugs, however.
The proposed release schedule is in ReleaseGoals.
What power does the RM wield?
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) has been followed, they should "roll" the release out. Of those 3 votes, 1 generally comes from the RM, and 2 from other committers.
What can I call this release?
There are three names for releases approved by the PMC:
- pre-releases (alpha): "3.1.0-pre1", "3.1.0-pre2", etc.
- release candidates (beta): "3.1.0-rc1", "3.1.0-rc2", etc.
- full release (general availability): "3.1.0"
The type of release needs to be chosen before beginning the release procedure since it is part of the tagging of the tree, etc.
Note the use of a dash between the version number and "pre"/"rc" strings; a dash is used, not a space, underscore, or no character at all.
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.
Typically, we do at least one RC before a full release.
Who can vote?
Committers & 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 votes cast by PMC members 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. In addition, the RM may decide against making a release even if the required votes have been made.
Full (general availability) releases require 3 +1's from PMC members and the release can be made as soon as a minimum quorum of three +1's from PMC members is met. See Apache Voting Procedure.
Pre-releases and RC's can be created and uploaded with just "lazy consensus" – ie. it's all go unless someone speaks up to object. However, you need to make it clear they are not equivalent to a "full"/"official" release – they cannot be uploaded to the "real" website download directories (ie www.apache.org/dist), or announced as a full release via a mail to the announce list. Make it clear that this is an unofficial "test build" by placing it in your public_html dir – e.g. https://people.apache.org/~jm/devel/ – for download.
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 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.