Salt Release Process

The goal for Salt projects is to cut a new feature release every six 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 2019.2.0 release as an example):

  1. Create first public draft of release notes with major features.

  2. Remove any deprecations for the upcoming release.

  3. Notify salt-users and salt-announce google groups when the feature freeze branch creation will occur so they can try to get their work merged.

  4. Create QA test plan. Review features planned for the release and determine if there is sufficient test coverage.

  5. Ensure all required features are merged.

  6. Complete one last merge forward from the previous branch.

  7. Create feature release branch with the name of the release. (ex. fluorine)

  8. Create issue to start the process of deprecating for the next feature release.

  9. Create jenkins jobs to test the new feature release branch.

  10. Inform salt-users and salt-announce google groups feature branch and freeze is complete.

  11. Add new feature branch to salt-jenkins repo and the kitchen yaml file.

  12. Fix tests failing in jenkins test runs.

  13. Finalize QA test plan and add all required tests.

  14. Run through a manual test run based off of the head of the feature branch.

  15. Convert the feature release branch to the version number. For example (v2019.2) This is based off of the year and month that is planned to release.

  16. Migrate both the jenkins test jobs and salt-jenkins repo to the new branch number.

  17. Notify salt-users and salt-announce google groups of the new version branch number and migrate any PRs to the new branch.

  18. Delete old feature release branch name (ex. fluorine)

  19. Update all name references to version number in the docs. For example all fluorine references in the docs needs to be moved to v2019.2.0

  20. Create RC release branch. (ex. 2019.2.0.rc)

  21. Create new jenkins test jobs with new RC release branch

  22. Notify salt-users and salt-announce google groups of the new RC branch.

  23. Fix tests failing in jenkins test runs.

  24. Review the release notes with major features.

  25. Generate the new man pages for the release.

  26. Create internal RC tag for testing.

  27. Build latest windows, mac, ubuntu, debian and redhat packages.

  28. Run manual and package tests against new RC packages.

  29. Update release candidate docs with the new version. (ex. 2019.2.0rc1)

  30. Push the internal tag live to salt's repo.

  31. Publish release archive to pypi based off tag.

  32. Push the RC packages live.

  33. Announce new RC to salt-users and salt-announce google groups.

  34. Triage incoming issues based on the new RC release.

  35. Fix RC issues once they are categorized as a release blocker.

  36. Depending on the issues found during the RC process make a decesion on whether to release based off the RC or go through another RC process, repeating the steps starting at ensuring the tests are not failing.

  37. If a RC is categorized as stable, build all required packages.

  38. Test all release packages.

  39. Test links from repo.saltstack.com.

  40. Update installation instructions with new release number at repo.saltstack.com.

  41. Update and build docs to include new version (2019.2) as the latest.

  42. Pre-announce on salt-users google group that we are about to update our repo.

  43. Publish release (v2019.2.0) archive to pypi based off tag.

  44. Publish all packages live to repo.

  45. Publish the docs.

  46. Create release at github

  47. Update win-repo-ng with new salt versions.

  48. Announce release is live to irc, salt-users, salt-announce and release slack community channel.

Maintenance and Bugfix Releases

Once a feature release branch has been cut from develop, the branch moves into a "feature freeze" state. The new release branch enters the merge-forward chain and only bugfixes should be applied against the new branch. Once major bugs have been fixed, a bugfix release can be cut:

  1. Ensure all required bug fixes are merged.

  2. Inform salt-users and salt-announce we are going to branch for the release.

  3. Complete one last merge forward from the previous branch.

  4. Create release branch with the version of the release. (ex. 2019.2.1)

  5. Create jenkins jobs that test the new release branch.

  6. Fix tests failing in jeknins test runs.

  7. Run through a manual test run based off of the head of the branch.

  8. Generate the new man pages for the release.

  9. Create internal tag for testing.(ex v2019.2.1)

  10. Build all release packages.

  11. Run manual and package tests against new packages.

  12. Update installation instructions with new release number at repo.saltstack.com.

  13. Update and build docs to include new version. (ex. 2019.2.1)

  14. Pre-announce on salt-users google groups that we are about to update our repo.

  15. Push the internal tag live to salt's repo.

  16. Publish release archive to pypi based off tag.

  17. Push the packages live.

  18. Publish release (v2019.2.1) archive to pypi based off tag.

  19. Publish all packages live to repo.

  20. Publish the docs.

  21. Create release at github

  22. Update win-repo-ng with new salt versions.

  23. Announce release is live to irc, salt-users, salt-announce and release slack channel.

For more information about the difference between the develop branch and bugfix release branches, please refer to the Which Salt Branch? section of Salt's Contributing documentation.