valitydev/salt
14
0
Fork 0
mirror of https://github.com/valitydev/salt.git synced 2024-11-07 17:09:03 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #33253 from rallytime/fix-30605

Browse Source 
Update the release process docs
This commit is contained in:
Thomas S Hatch 2016-05-13 15:28:11 -06:00
commit 94a53da92e
1 changed files with 10 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -3,7 +3,7 @@ Salt Release Process
====================
The goal for Salt projects is to cut a new feature release every four to six
weeks. 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.
@ -25,7 +25,7 @@ example):
numbers. (e.g. ``0.16``)
#. On this new branch, create an annotated tag for the first revision release,
which is generally a release candidate. It should be preceded by the letter
``v``. (e.g. ``v0.16.0RC``)
``v``. (e.g. ``v0.16.0rc1``)
#. The release should be packaged from this annotated tag and uploaded to PyPI
as well as the GitHub releases page for this tag.
#. The packagers should be notified on the `salt-packagers`_ mailing list so
@ -39,10 +39,10 @@ example):
Maintenance and Bugfix Releases
===============================
Once a release has been cut, regular cherry-picking sessions should begin to
cherry-pick any bugfixes from the ``develop`` branch to the release branch
(e.g. ``0.16``). Once major bugs have been fixes and cherry-picked, a bugfix
release can be cut:
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:
#. On the release branch (i.e. ``0.16``), create an annotated tag for the
revision release. It should be preceded by the letter ``v``. (e.g.
@ -53,19 +53,7 @@ release can be cut:
#. After the packagers have been given a few days to compile the packages, the
release is announced on the `salt-users`_ mailing list.
Cherry-Picking Process for Bugfixes
===================================
Bugfixes should be made on the ``develop`` branch. If the bug also applies to
the current release branch, then on the pull request against ``develop``, the
user should mention ``@basepi`` and ask for the pull request to be
cherry-picked. If it is verified that the fix is a bugfix, then the
``Bugfix -- Cherry-Pick`` label will be applied to the pull request. When
those commits are cherry-picked, the label will be switched to the
``Bugfix -- [Done] Cherry-Pick`` label. This allows easy recognition of which
pull requests have been cherry-picked, and which are still pending to be
cherry-picked. All cherry-picked commits will be present in the next release.
Features will not be cherry-picked, and will be present in the next feature
release.
For more information about the difference between the ``develop`` branch and
bugfix release branches, please refer to the :ref:`Which Salt Branch?
<which-salt-branch>` section of Salt's :ref:`Contributing <contributing>`
documentation.