Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: [Original edit by JustinMason] add example version strings, and some notes about RCs

...

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?

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.

...