12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091 |
- ====================
- 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 decesion
- 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.saltstack.com`_.
- #. Update installation instructions with new release number at `repo.saltstack.com`_.
- #. Review and update all impacted :ref:`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)
- #. Create jenkins jobs that test the new release branch.
- #. 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.saltstack.com`_.
- #. 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.
- For more information about the difference between the ``master`` branch and
- bugfix release branches, please refer to the :ref:`Which Salt Branch?
- <which-salt-branch>` section of Salt's :ref:`Contributing <contributing>`
- documentation.
- .. _`github`: https://github.com/saltstack/salt/releases
- .. _`repo.saltstack.com`: https://repo.saltstack.com
|