Salt Release Process

The goal for Salt projects is to cut a new feature release every four to six weeks. This document outlines the process for these releases, and the subsequent bug fix releases which follow.

Feature Release Process

When a new release is ready to be cut, the person responsible for cutting the release will follow the following steps (written using the 0.16 release as an example):

  1. All open issues on the release milestone should be moved to the next release milestone. (e.g. from the 0.16 milestone to the 0.17 milestone)
  2. Release notes should be created documenting the major new features and bugfixes in the release.
  3. Create an annotated tag with only the major and minor version numbers, preceded by the letter v. (e.g. v0.16) This tag will reside on the develop branch.
  4. Create a branch for the new release, using only the major and minor version numbers. (e.g. 0.16)
  5. On this new branch, create an annotated tag for the first revision release, which is generally a release candidate. It should be preceded by the letter v. (e.g. v0.16.0RC)
  6. The release should be packaged from this annotated tag and uploaded to PyPI as well as the GitHub releases page for this tag.
  7. The packagers should be notified on the salt-packagers mailing list so they can create packages for all the major operating systems. (note that release candidates should go in the testing repositories)
  8. After the packagers have been given a few days to compile the packages, the release is announced on the salt-users mailing list.
  9. Log into RTD and add the new release there. (Have to do it manually)

Maintenance and Bugfix Releases

Once a release has been cut, regular cherry-picking sessions should begin to cherry-pick any bugfixes from the develop branch to the release branch (e.g. 0.16). Once major bugs have been fixes and cherry-picked, a bugfix release can be cut:

  1. On the release branch (i.e. 0.16), create an annotated tag for the revision release. It should be preceded by the letter v. (e.g. v0.16.2) Release candidates are unnecessary for bugfix releases.
  2. The release should be packaged from this annotated tag and uploaded to PyPI.
  3. The packagers should be notified on the salt-packagers mailing list so they can create packages for all the major operating systems.
  4. After the packagers have been given a few days to compile the packages, the release is announced on the salt-users mailing list.

Cherry-Picking Process for Bugfixes

Bugfixes should be made on the develop branch. If the bug also applies to the current release branch, then on the pull request against develop, the user should mention @basepi and ask for the pull request to be cherry-picked. If it is verified that the fix is a bugfix, then the Bugfix -- Cherry-Pick label will be applied to the pull request. When those commits are cherry-picked, the label will be switched to the Bugfix -- [Done] Cherry-Pick label. This allows easy recognition of which pull requests have been cherry-picked, and which are still pending to be cherry-picked. All cherry-picked commits will be present in the next release.

Features will not be cherry-picked, and will be present in the next feature release.