mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Improve release and development cycle documentation
This commit: - Adds a table highlighting the status of each version and provides a link to each major release's changelog - Re-inforces how stable versions are maintained and for how long - Moves this documentation out of the developer tree (this is interesting for users too!) while keeping a link there.
This commit is contained in:
David Moreau-Simard
Toshio Kuratomi
parent
90a42d1e53
commit
e2d874c744
4 changed files with 139 additions and 59 deletions
|
|
@ -1,57 +0,0 @@
|
|||
Releases
|
||||
========
|
||||
|
||||
.. contents:: Topics
|
||||
:local:
|
||||
|
||||
.. _support_life:
|
||||
|
||||
Support for older releases
|
||||
``````````````````````````
|
||||
|
||||
Ansible supports the two most recent major, stable releases. Security- and bug-related fixes may be implemented in older versions, but this
|
||||
support is not guaranteed.
|
||||
|
||||
If you are on a release older than the last two major, stable releases, please see our `Porting Guide <http://docs.ansible.com/ansible/porting_guide_2.0.html>`_.
|
||||
|
||||
.. _schedule:
|
||||
|
||||
Release schedule
|
||||
````````````````
|
||||
Ansible is on a 'flexible' 4 month release schedule. Sometimes the release cycle can be extended if there is a major change that requires more time (for example, a core rewrite).
|
||||
Recently the main Ansible repo `merged <https://docs.ansible.com/ansible/dev_guide/repomerge.html>`_ the separated ansible-modules-core and ansible-modules-extras repos, as such modules get released at the same time as the main Ansible repo.
|
||||
|
||||
The major features and bugs fixed in a release should be reflected in the `CHANGELOG.md <https://github.com/ansible/ansible/blob/devel/CHANGELOG.md>`_. Minor features and bug fixes will be shown in the commit history. For example, `issue #19057 <https://github.com/ansible/ansible/pull/19057>`_ is reflected only in the commit history.
|
||||
When a fix orfeature gets added to the `devel` branch it will be part of the next release. Some bugfixes can be backported to previous releases and will be part of a minor point release if such a release is deemed necessary.
|
||||
|
||||
Sometimes a release candidate can be extended by a few days if a bug fix makes a change that can have far-reaching consequences, so users have enough time to find any new issues that may stem from this.
|
||||
|
||||
.. _methods:
|
||||
|
||||
Release methods
|
||||
````````````````
|
||||
|
||||
Ansible normally goes through a 'release candidate', issuing an RC1 for a release. If no major bugs are discovered in the release candidate after 5 business days, we'll get a final release. Otherwise, fixes will be applied and an RC2 will be provided for testing. If no bugs are discovered in RC2 after 2 days, the final release will be made, iterating this last step and incrementing the candidate number as we find major bugs.
|
||||
|
||||
|
||||
.. _freezing:
|
||||
|
||||
Release feature freeze
|
||||
``````````````````````
|
||||
|
||||
During the release candidate process, the focus will be on bugfixes that affect the RC, new features will be delayed while we try to produce a final version. Some bugfixes that are minor or don't affect the RC will also be postponed until after the release is finalized.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:doc:`developing_api`
|
||||
Python API to Playbooks and Ad Hoc Task Execution
|
||||
:doc:`developing_modules`
|
||||
How to develop modules
|
||||
:doc:`developing_plugins`
|
||||
How to develop plugins
|
||||
`Ansible Tower <https://ansible.com/ansible-tower>`_
|
||||
REST API endpoint and GUI for Ansible, syncs with dynamic inventory
|
||||
`Development Mailing List <http://groups.google.com/group/ansible-devel>`_
|
||||
Mailing list for development topics
|
||||
`irc.freenode.net <http://irc.freenode.net>`_
|
||||
#ansible IRC chat channel
|
||||
|
|
@ -33,6 +33,6 @@ To get started, select one of the following topics.
|
|||
developing_rebasing
|
||||
testing
|
||||
repomerge
|
||||
developing_releases
|
||||
../release_and_maintenance
|
||||
../committer_guidelines
|
||||
./style_guide/index
|
||||
|
|
|
|||
|
|
@ -42,4 +42,4 @@ Ansible, Inc. releases a new major release of Ansible approximately every two mo
|
|||
YAMLSyntax
|
||||
porting_guide_2.0
|
||||
python_3_support
|
||||
|
||||
release_and_maintenance
|
||||
|
|
|
|||
137
docs/docsite/rst/release_and_maintenance.rst
Normal file
137
docs/docsite/rst/release_and_maintenance.rst
Normal file
|
|
@ -0,0 +1,137 @@
|
|||
Release and maintenance
|
||||
=======================
|
||||
|
||||
.. contents:: Topics
|
||||
:local:
|
||||
|
||||
.. _schedule:
|
||||
|
||||
Release cycle
|
||||
`````````````
|
||||
|
||||
Ansible is developed and released on a flexible 4 months release cycle.
|
||||
This cycle can be extended in order to allow for larger changes to be properly
|
||||
implemented and tested before a new release is made available.
|
||||
|
||||
Ansible supports the two most recent major stable releases.
|
||||
For more information, read about the
|
||||
`development and stable version maintenance workflow`_.
|
||||
|
||||
If you are using a release of Ansible that is no longer supported, we strongly
|
||||
encourage you to upgrade as soon as possible in order to benefit from the
|
||||
latest features and security fixes.
|
||||
|
||||
Older unsupported versions of Ansible can contain unfixed security
|
||||
vulnerabilities (*CVE*).
|
||||
|
||||
You can refer to the `porting guide`_ for tips on updating your Ansible
|
||||
playbooks to run on newer versions.
|
||||
|
||||
.. _porting guide: https://docs.ansible.com/ansible/porting_guide_2.0.html
|
||||
|
||||
Release status
|
||||
``````````````
|
||||
|
||||
+-----------------+----------------------------+----------------------------------------+
|
||||
| Ansible release | Latest version | Status |
|
||||
+=================+============================+========================================+
|
||||
| devel | `2.4`_ (unreleased, trunk) | In development |
|
||||
+-----------------+----------------------------+----------------------------------------+
|
||||
| 2.3 | `2.3.1`_ (2017-06-01) | Supported (bug **and** security fixes) |
|
||||
+-----------------+----------------------------+----------------------------------------+
|
||||
| 2.2 | `2.2.3`_ (2017-05-09) | Supported (**only** security fixes) |
|
||||
+-----------------+----------------------------+----------------------------------------+
|
||||
| 2.1 | `2.1.6`_ (2017-06-01) | Unsupported (end of life) |
|
||||
+-----------------+----------------------------+----------------------------------------+
|
||||
| 2.0 | `2.0.2`_ (2016-04-19) | Unsupported (end of life) |
|
||||
+-----------------+----------------------------+----------------------------------------+
|
||||
| 1.9 | `1.9.6`_ (2016-04-15) | Unsupported (end of life) |
|
||||
+-----------------+----------------------------+----------------------------------------+
|
||||
| <1.9 | n/a | Unsupported (end of life) |
|
||||
+-----------------+----------------------------+----------------------------------------+
|
||||
|
||||
.. _2.4: https://github.com/ansible/ansible/blob/devel/CHANGELOG.md
|
||||
.. _2.3.1: https://github.com/ansible/ansible/blob/stable-2.3/CHANGELOG.md
|
||||
.. _2.2.3: https://github.com/ansible/ansible/blob/stable-2.2/CHANGELOG.md
|
||||
.. _2.1.6: https://github.com/ansible/ansible/blob/stable-2.1/CHANGELOG.md
|
||||
.. _2.0.2: https://github.com/ansible/ansible/blob/stable-2.0/CHANGELOG.md
|
||||
.. _1.9.6: https://github.com/ansible/ansible/blob/stable-1.9/CHANGELOG.md
|
||||
|
||||
.. _support_life:
|
||||
.. _methods:
|
||||
|
||||
Development and stable version maintenance workflow
|
||||
```````````````````````````````````````````````````
|
||||
|
||||
The Ansible community develops and maintains Ansible on GitHub_.
|
||||
|
||||
New modules, plugins, features and bugfixes will always be integrated in what
|
||||
will become the next major version of Ansible.
|
||||
This work is tracked on the ``devel`` git branch.
|
||||
|
||||
Ansible provides bugfixes and security improvements for the most recent major
|
||||
release while the previous major release will only receive security patches.
|
||||
This work is tracked on the ``stable-<version>`` git branches.
|
||||
|
||||
The fixes that land in supported stable branches will eventually be released
|
||||
as a new version when necessary.
|
||||
|
||||
For more information on the changes included in each new version, you can refer
|
||||
to the changelog_, available on GitHub.
|
||||
|
||||
Note that while there are no guarantees for providing fixes for unsupported
|
||||
releases of Ansible, there can sometimes be exceptions for critical issues.
|
||||
|
||||
.. _GitHub: https://github.com/ansible/ansible
|
||||
.. _changelog: https://github.com/ansible/ansible/blob/devel/CHANGELOG.md
|
||||
|
||||
Release candidates
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Before a new release or version of Ansible can be done, it will typically go
|
||||
through a release candidate process.
|
||||
|
||||
This provides the Ansible community the opportunity to test Ansible and report
|
||||
bugs or issues they might come across.
|
||||
|
||||
Ansible tags the first release candidate (``RC1``) which is usually scheduled
|
||||
to last five business days. The final release is done if no major bugs or
|
||||
issues are identified during this period.
|
||||
|
||||
If there are major problems with the first candidate, a second candidate will
|
||||
be tagged (``RC2``) once the necessary fixes have landed.
|
||||
This second candidate lasts for a shorter duration than the first.
|
||||
If no problems have been reported after two business days, the final release is
|
||||
done.
|
||||
|
||||
More release candidates can be tagged as required, so long as there are
|
||||
bugs that the Ansible core maintainers consider should be fixed before the
|
||||
final release.
|
||||
|
||||
.. _freezing:
|
||||
|
||||
Feature freeze
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
While there is a pending release candidate, the focus of core developers and
|
||||
maintainers will on fixes towards the release candidate.
|
||||
|
||||
Merging new features or fixes that are not related to the release candidate may
|
||||
be delayed in order to allow the new release to be shipped as soon as possible.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:doc:`committer_guidelines`
|
||||
Guidelines for Ansible core contributors and maintainers
|
||||
:doc:`test_strategies`
|
||||
Testing strategies
|
||||
:doc:`community`
|
||||
Community information and contributing
|
||||
`Ansible Changelog <https://github.com/ansible/ansible/blob/devel/CHANGELOG.md>`_
|
||||
Documentation of the improvements for each version of Ansible
|
||||
`Ansible release tarballs <https://releases.ansible.com/ansible/>`_
|
||||
Ansible release tarballs
|
||||
`Development Mailing List <http://groups.google.com/group/ansible-devel>`_
|
||||
Mailing list for development topics
|
||||
`irc.freenode.net <http://irc.freenode.net>`_
|
||||
#ansible IRC chat channel
|
||||
Loading…
Reference in a new issue