2013-06-28 11:23:48 -06:00
|
|
|
====================
|
|
|
|
|
Salt Release Process
|
|
|
|
|
====================
|
|
|
|
|
|
2020-02-11 11:04:14 -05:00
|
|
|
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
|
2013-06-28 11:23:48 -06:00
|
|
|
subsequent bug fix releases which follow.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Feature Release Process
|
|
|
|
|
=======================
|
|
|
|
|
|
|
|
|
|
When a new release is ready to be cut, the person responsible for cutting the
|
2020-02-11 11:04:14 -05:00
|
|
|
release will follow the following steps (written using the 3000 release as an
|
2013-06-28 11:23:48 -06:00
|
|
|
example):
|
|
|
|
|
|
2019-03-01 10:21:02 -05:00
|
|
|
#. 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
|
2020-02-11 11:04:14 -05:00
|
|
|
all neon references in the docs needs to be moved to v3000
|
2019-03-01 10:21:02 -05:00
|
|
|
#. Review the release notes with major features.
|
|
|
|
|
#. Generate the new man pages for the release.
|
2020-02-11 11:04:14 -05:00
|
|
|
#. Create internal RC tag for testing from the head of the master branch.
|
2019-03-01 10:21:02 -05:00
|
|
|
#. 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.
|
2022-07-06 14:25:47 -04:00
|
|
|
#. Depending on the issues found during the RC process make a decision
|
2020-02-11 11:04:14 -05:00
|
|
|
on whether to release based off the RC or go through another RC process
|
2019-03-01 10:21:02 -05:00
|
|
|
#. If a RC is categorized as stable, build all required packages.
|
|
|
|
|
#. Test all release packages.
|
2021-08-12 16:26:29 +00:00
|
|
|
#. Test links from `repo.saltproject.io`_.
|
|
|
|
|
#. Update installation instructions with new release number at `repo.saltproject.io`_.
|
2020-06-24 11:33:22 -05:00
|
|
|
#. Review and update all impacted :ref:`installation` documentation.
|
2020-02-11 11:04:14 -05:00
|
|
|
#. Update and build docs to include new version (3000) as the latest.
|
2019-03-01 10:21:02 -05:00
|
|
|
#. Pre-announce on salt-users google group that we are about to update our repo.
|
2020-02-11 11:04:14 -05:00
|
|
|
#. Publish release (v3000) archive to pypi based off tag.
|
2019-03-01 10:21:02 -05:00
|
|
|
#. 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.
|
2013-06-28 11:23:48 -06:00
|
|
|
|
|
|
|
|
|
2020-02-11 11:04:14 -05:00
|
|
|
Bugfix Releases
|
|
|
|
|
===============
|
2013-06-28 11:23:48 -06:00
|
|
|
|
2020-02-11 11:04:14 -05:00
|
|
|
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.
|
2013-06-28 11:23:48 -06:00
|
|
|
|
2019-03-01 10:21:02 -05:00
|
|
|
#. Ensure all required bug fixes are merged.
|
2020-02-11 11:04:14 -05:00
|
|
|
#. Create release branch with the version of the release. (ex. 3000.1)
|
2019-03-01 10:21:02 -05:00
|
|
|
#. Run through a manual test run based off of the head of the branch.
|
|
|
|
|
#. Generate the new man pages for the release.
|
2020-02-11 11:04:14 -05:00
|
|
|
#. Create internal tag for testing.(ex v3000.1)
|
2019-03-01 10:21:02 -05:00
|
|
|
#. Build all release packages.
|
|
|
|
|
#. Run manual and package tests against new packages.
|
2021-08-12 16:26:29 +00:00
|
|
|
#. Update installation instructions with new release number at `repo.saltproject.io`_.
|
2020-02-11 11:04:14 -05:00
|
|
|
#. Update and build docs to include new version. (ex. 3000.1)
|
2019-03-01 10:21:02 -05:00
|
|
|
#. 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.
|
2020-02-11 11:04:14 -05:00
|
|
|
#. Publish release (v3000) archive to pypi based off tag.
|
2019-03-01 10:21:02 -05:00
|
|
|
#. 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.
|
2014-06-19 16:17:46 -06:00
|
|
|
|
2019-03-01 10:21:02 -05:00
|
|
|
.. _`github`: https://github.com/saltstack/salt/releases
|
2021-08-12 16:26:29 +00:00
|
|
|
.. _`repo.saltproject.io`: https://repo.saltproject.io
|
