Salt Release Process¶

The goal for Salt projects is to cut a new feature release every three to four months. 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 3000 release as an example):

Create first public draft of release notes with major features.
Remove any deprecations for the upcoming release.
Ensure all required features are merged.
Create issue to start the process of deprecating for the next feature release.
Run through a manual test run based off of the head of the feature branch.
Update all name references to version number in the docs. For example all neon references in the docs needs to be moved to v3000
Review the release notes with major features.
Generate the new man pages for the release.
Create internal RC tag for testing from the head of the master branch.
Build latest windows, mac, ubuntu, debian and redhat packages.
Run manual and package tests against new RC packages.
Push the internal tag live to salt's repo.
Publish release archive to pypi based off tag.
Push the RC packages live.
Announce new RC to salt-users and salt-announce google groups.
Triage incoming issues based on the new RC release.
Fix RC issues once they are categorized as a release blocker.
Depending on the issues found during the RC process make a decision on whether to release based off the RC or go through another RC process
If a RC is categorized as stable, build all required packages.
Test all release packages.
Test links from repo.saltproject.io.
Update installation instructions with new release number at repo.saltproject.io.
Review and update all impacted Installation documentation.
Update and build docs to include new version (3000) as the latest.
Pre-announce on salt-users google group that we are about to update our repo.
Publish release (v3000) archive to pypi based off tag.
Publish all packages live to repo.
Publish the docs.
Create release at github
Update win-repo-ng with new salt versions.
Announce release is live to irc, salt-users, salt-announce and release slack community channel.

Bugfix Releases¶

Once a feature release branch has been cut from the master branch, if serious bugs or a CVE is found for the most recent release a bugfix release will need to be cut. A temporary branch will be created based off of the previous release tag. For example, if it is determined that a 3000.1 release needs to occur a 3000.1 branch will be created based off of the v3000 tag. The fixes that need to go into 3000.1 will be added and merged into this branch. Here are the steps for a bugfix release.

Ensure all required bug fixes are merged.
Create release branch with the version of the release. (ex. 3000.1)
Run through a manual test run based off of the head of the branch.
Generate the new man pages for the release.
Create internal tag for testing.(ex v3000.1)
Build all release packages.
Run manual and package tests against new packages.
Update installation instructions with new release number at repo.saltproject.io.
Update and build docs to include new version. (ex. 3000.1)
Pre-announce on salt-users google groups that we are about to update our repo.
Push the internal tag live to salt's repo.
Publish release archive to pypi based off tag.
Push the packages live.
Publish release (v3000) archive to pypi based off tag.
Publish all packages live to repo.
Publish the docs.
Create release at github
Update win-repo-ng with new salt versions.
Announce release is live to irc, salt-users, salt-announce and release slack channel.