THIS IS A DRAFT
Core documents
We The guiding principles for releases are found in Apache Release Policy and Release Creation Process. 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 member of the Apache SpamAssassin PMC can make a release designated with Apache. Any committer of the Apache SpamAssassin project can make a release designated with Apacheperform most of the steps of producing a release package, but some of the final steps to making it an official Apache release, will require a member of the PMC with appropriate access agreeing to assume the role of Release Manager.
Who is in charge of a release?
The release is coordinated by the Release Manager (RM). Since this job requires coordination of To become an RM for a release, one must be a member of the PMC who volunteers to be RM. Any such person will be given access to the project signing key and passphrase, as well as PAUSE co-maintainer status to the Mail::SpamAssassin module on CPAN. The access to the signing key and PAUSE are only to be given to members of the PMC when they have a reasonable expectation of being a Release Manager for a release. It is an acceptable alternative for the Release Manager to generate a new signing key for the new release and publish the public key in all the places specified in the build/README documentation.
There the development community (and access to SVN), only committers to the project can be RM. However, there is no set RM. Any committer PMC member 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.)by definition is not a build for private distribution within the SpamAssassin development community. Such a private distribution is referred to as a snapshot. Since a snapshot does not need to be signed with an official project key and since it can't be uploaded to CPAN, any committer can produce a snapshot build. An RM can delegate most of the process of producing a release to a committer, as long as the RM takes final responsibility for the result and handles the signing, upload to CPAN, and upload to the Apache release directories that also require PMC membership for write access.
When do I know if it is a good time to release?
...
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.
...
- 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.
...
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 committers 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. 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.
Full (general availability) releases require 3 +1's from PMC members . This is unfortunate, but it's a requirement of the ASF's bylawsand 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. http https://people.apache.org/~jm/devel/ – for download.
Oops. We found a problem
...