mirror of
https://github.com/valitydev/salt.git
synced 2024-11-09 01:36:48 +00:00
498a612078
Conflicts: doc/topics/cloud/linode.rst doc/topics/cloud/misc.rst doc/topics/cloud/parallels.rst doc/topics/cloud/proxmox.rst Conflicts: doc/topics/development/architecture.rst doc/topics/development/translating.rst
71 lines
3.4 KiB
ReStructuredText
71 lines
3.4 KiB
ReStructuredText
====================
|
|
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
|
|
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 0.16 release as an
|
|
example):
|
|
|
|
#. All open issues on the release milestone should be moved to the next release
|
|
milestone. (e.g. from the ``0.16`` milestone to the ``0.17`` milestone)
|
|
#. Release notes should be created documenting the major new features and
|
|
bugfixes in the release.
|
|
#. Create an annotated tag with only the major and minor version numbers,
|
|
preceded by the letter ``v``. (e.g. ``v0.16``) This tag will reside on the
|
|
``develop`` branch.
|
|
#. Create a branch for the new release, using only the major and minor version
|
|
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``)
|
|
#. 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
|
|
they can create packages for all the major operating systems. (note that
|
|
release candidates should go in the testing repositories)
|
|
#. After the packagers have been given a few days to compile the packages, the
|
|
release is announced on the `salt-users`_ mailing list.
|
|
#. Log into RTD and add the new release there. (Have to do it manually)
|
|
|
|
|
|
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:
|
|
|
|
#. 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.
|
|
``v0.16.2``) Release candidates are unnecessary for bugfix releases.
|
|
#. The release should be packaged from this annotated tag and uploaded to PyPI.
|
|
#. The packagers should be notified on the `salt-packagers`_ mailing list so
|
|
they can create packages for all the major operating systems.
|
|
#. 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. |