valitydev/salt
14
0
Fork 0
mirror of https://github.com/valitydev/salt.git synced 2024-11-06 16:45:27 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Update release documentation

Browse Source
This commit is contained in:
Ch3LL 2019-03-01 10:21:02 -05:00
parent 1fa2072521
commit 9a681367a6
No known key found for this signature in database
GPG Key ID: 132B55A7C13EFA73
2 changed files with 91 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

115
doc/topics/development/conventions/release.rst
View File

@ -2,7 +2,7 @@
Salt Release Process Salt Release Process
==================== ====================
The goal for Salt projects is to cut a new feature release every four to six 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 months. This document outlines the process for these releases, and the
subsequent bug fix releases which follow. subsequent bug fix releases which follow.
@ -11,29 +11,66 @@ Feature Release Process
======================= =======================
When a new release is ready to be cut, the person responsible for cutting the 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 release will follow the following steps (written using the 2019.2.0 release as an
example): example):
#. All open issues on the release milestone should be moved to the next release #. Create first public draft of release notes with major features.
milestone. (e.g. from the ``0.16`` milestone to the ``0.17`` milestone) #. Remove any deprecations for the upcoming release.
#. Release notes should be created documenting the major new features and #. Notify salt-users and salt-announce google groups when the feature freeze
bugfixes in the release. branch creation will occur so they can try to get their work merged.
#. Create an annotated tag with only the major and minor version numbers, #. Create QA test plan. Review features planned for the release and determine if
preceded by the letter ``v``. (e.g. ``v0.16``) This tag will reside on the there is sufficient test coverage.
``develop`` branch. #. Ensure all required features are merged.
#. Create a branch for the new release, using only the major and minor version #. Complete one last merge forward from the previous branch.
numbers. (e.g. ``0.16``) #. Create feature release branch with the name of the release. (ex. fluorine)
#. On this new branch, create an annotated tag for the first revision release, #. Create issue to start the process of deprecating for the next feature release.
which is generally a release candidate. It should be preceded by the letter #. Create jenkins jobs to test the new feature release branch.
``v``. (e.g. ``v0.16.0rc1``) #. Inform salt-users and salt-announce google groups feature branch and
#. The release should be packaged from this annotated tag and uploaded to PyPI freeze is complete.
as well as the GitHub releases page for this tag. #. Add new feature branch to salt-jenkins repo and the kitchen yaml file.
#. The packagers should be notified on the `salt-packagers`_ mailing list so #. Fix tests failing in jenkins test runs.
they can create packages for all the major operating systems. (note that #. Finalize QA test plan and add all required tests.
release candidates should go in the testing repositories) #. Run through a manual test run based off of the head of the feature branch.
#. After the packagers have been given a few days to compile the packages, the #. Convert the feature release branch to the version number. For example (v2019.2)
release is announced on the `salt-users`_ mailing list. This is based off of the year and month that is planned to release.
#. Log into RTD and add the new release there. (Have to do it manually) #. Migrate both the jenkins test jobs and salt-jenkins repo to the new branch number.
#. Notify salt-users and salt-announce google groups of the new version branch
number and migrate any PRs to the new branch.
#. Delete old feature release branch name (ex. fluorine)
#. 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
#. Create RC release branch. (ex. 2019.2.0.rc)
#. Create new jenkins test jobs with new RC release branch
#. Notify salt-users and salt-announce google groups of the new RC branch.
#. Fix tests failing in jenkins test runs.
#. Review the release notes with major features.
#. Generate the new man pages for the release.
#. Create internal RC tag for testing.
#. Build latest windows, mac, ubuntu, debian and redhat packages.
#. Run manual and package tests against new RC packages.
#. Update release candidate docs with the new version. (ex. 2019.2.0rc1)
#. 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,
repeating the steps starting at ensuring the tests are not failing.
#. 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`_.
#. Update and build docs to include new version (2019.2) as the latest.
#. Pre-announce on salt-users google group that we are about to update our repo.
#. Publish release (v2019.2.0) 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.
Maintenance and Bugfix Releases Maintenance and Bugfix Releases
@ -44,16 +81,34 @@ 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 chain and only bugfixes should be applied against the new branch. Once major bugs
have been fixed, a bugfix release can be cut: have been fixed, a bugfix release can be cut:
#. On the release branch (i.e. ``0.16``), create an annotated tag for the #. Ensure all required bug fixes are merged.
revision release. It should be preceded by the letter ``v``. (e.g. #. Inform salt-users and salt-announce we are going to branch for the release.
``v0.16.2``) Release candidates are unnecessary for bugfix releases. #. Complete one last merge forward from the previous branch.
#. The release should be packaged from this annotated tag and uploaded to PyPI. #. Create release branch with the version of the release. (ex. 2019.2.1)
#. The packagers should be notified on the `salt-packagers`_ mailing list so #. Create jenkins jobs that test the new release branch.
they can create packages for all the major operating systems. #. Fix tests failing in jeknins test runs.
#. After the packagers have been given a few days to compile the packages, the #. Run through a manual test run based off of the head of the branch.
release is announced on the `salt-users`_ mailing list. #. Generate the new man pages for the release.
#. Create internal tag for testing.(ex v2019.2.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. 2019.2.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 (v2019.2.1) 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 ``develop`` branch and For more information about the difference between the ``develop`` branch and
bugfix release branches, please refer to the :ref:`Which Salt Branch? bugfix release branches, please refer to the :ref:`Which Salt Branch?
<which-salt-branch>` section of Salt's :ref:`Contributing <contributing>` <which-salt-branch>` section of Salt's :ref:`Contributing <contributing>`
documentation. documentation.
.. _`github`: https://github.com/saltstack/salt/releases
.. _`repo.saltstack.com`: https://repo.saltstack.com

13
doc/topics/development/git/index.rst
View File

@ -68,11 +68,10 @@ related release branches.
For more information, please see the :ref:`Which Salt Branch? <which-salt-branch>` For more information, please see the :ref:`Which Salt Branch? <which-salt-branch>`
section of Salt's :ref:`Contributing <contributing>` documentation. section of Salt's :ref:`Contributing <contributing>` documentation.
Determining when a point release is going to be made is up to the project Generally point releases are made every 2 months or if there is a security fix
leader (Thomas Hatch). Generally point releases are made every 2-4 weeks or they can be made sooner.
if there is a security fix they can be made sooner.
The point release is only designated by tagging the commit on the release The point release is designated by branching (ex 2019.2.1) and then tagging (v2019.2.1)
branch with a release number using the existing convention (version 2015.8.1 from that newly created release branch when its determined the release is stable.
is tagged with v2015.8.1). From the tag point a new source tarball is generated From the tag point a new source tarball is generated and published to PyPI,
and published to PyPI, and a release announcement is made. and a release announcement is made.