Page History

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 member of the Apache SpamAssassin PMC can make a release designated with Apache. Any committer on 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 by definition is not a build for private distribution . A snapshot is more suitable for that.)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?

...

• 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.

...

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. http https://people.apache.org/~jm/devel/ – for download.

Oops. We found a problem

...