archive
/
ansible
mirror of https://github.com/ansible/ansible.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

point all older release pages to devel (#71428) (#71475)

Browse Source 
(cherry picked from commit 3be597419d)
stable-2.5
Sandra McCann 4 years ago committed by GitHub
parent 4f5084d9d2
commit 0d1ecee767
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 138 deletions
Show Stats Download Patch File Download Diff File

142
docs/docsite/rst/reference_appendices/release_and_maintenance.rst
Unescape Escape View File

@ -3,153 +3,19 @@
Release and maintenance Release and maintenance
======================= =======================
.. contents:: Topics
:local:
.. _release_cycle: .. _release_cycle:
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 has a graduated support structure that extends to three major releases.
For more information, read about the :ref:`development_and_stable_version_maintenance_workflow` or
see the chart in :ref:`release_schedule` for the degrees to which current releases are supported.
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 :ref:`porting guides<porting_guides>` for tips on updating your Ansible
playbooks to run on newer versions.
.. _release_schedule: .. _release_schedule:
Release status
``````````````
=============== ========================== =================================================
Ansible Release Latest Version Status
=============== ========================== =================================================
devel 2.8 (unreleased, trunk) In development
`2.7`_ 2.7.0 (2018-10-04) Supported (security **and** general bug fixes)
`2.6`_ 2.6.5 (2018-09-28) Supported (security **and** critical bug fixes)
`2.5`_ 2.5.9 (2018-09-10) Supported (security fixes)
`2.4`_ 2.4.6 (2018-07-05) Unsupported (end of life)
`2.3`_ 2.3.3 (2017-12-20) Unsupported (end of life)
`2.2`_ 2.2.3 (2017-05-09) Unsupported (end of life)
`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)
=============== ========================== =================================================
.. note:: Starting with Ansible-2.4, support lasts for 3 releases. Thus Ansible-2.4 will receive
security and general bug fixes when it is first released, security and critical bug fixes when
2.5 is released, and **only** security fixes once 2.6 is released.
.. Comment: devel used to point here but we're currently revamping our changelog process and have no
link to a static changelog for devel _2.6: https://github.com/ansible/ansible/blob/devel/CHANGELOG.md
.. _2.7: https://github.com/ansible/ansible/blob/stable-2.7/changelogs/CHANGELOG-v2.7.rst
.. _2.6: https://github.com/ansible/ansible/blob/stable-2.6/changelogs/CHANGELOG-v2.6.rst
.. _2.5: https://github.com/ansible/ansible/blob/stable-2.5/changelogs/CHANGELOG-v2.5.rst
.. _2.4: https://github.com/ansible/ansible/blob/stable-2.4/CHANGELOG.md
.. _2.3: https://github.com/ansible/ansible/blob/stable-2.3/CHANGELOG.md
.. _2.2: https://github.com/ansible/ansible/blob/stable-2.2/CHANGELOG.md
.. _2.1: https://github.com/ansible/ansible/blob/stable-2.1/CHANGELOG.md
.. _2.0: https://github.com/ansible/ansible/blob/stable-2.0/CHANGELOG.md
.. _1.9: https://github.com/ansible/ansible/blob/stable-1.9/CHANGELOG.md
.. _support_life: .. _support_life:
.. _methods: .. _methods:
.. _development_and_stable_version_maintenance_workflow: .. _development_and_stable_version_maintenance_workflow:
.. _release_changelogs:
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. The previous
major release will only receive fixes for security issues and critical bugs. Ansible only applies
security fixes to releases which are two releases old. This work is tracked on the
``stable-<version>`` git branches.
.. note:: Support for three major releases began with Ansible-2.4. Ansible-2.3 and older versions
are only supported for two releases with the first stage including both security and general bug
fixes while the second stage includes security and critical bug fixes
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.
.. _release_freezing: .. _release_freezing:
Feature freeze Please go to `the devel release and maintenance page <https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html>`_ for up to date information.
~~~~~~~~~~~~~~
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.
Deprecation Cycle
`````````````````
Sometimes we need to remove a feature, normally in favor of a reimplementation that we hope does a better job.
To do this we have a deprecation cycle. First we mark a feature as 'deprecated'. This is normally accompanied with warnings
to the user as to why we deprecated it, what alternatives they should switch to and when (which version) we are scheduled
to remove the feature permanently.
The cycle is normally across 4 feature releases (2.x.y, where the x marks a feature release and the y a bugfix release), .. note::
so the feature is normally removed in the 4th release after we announce the deprecation.
For example, something deprecated in 2.5 will be removed in 2.9, assuming we don't jump to 3.x before that point.
The tracking is tied to the number of releases, not the release numbering.
For modules/plugins, we keep the documentation after the removal for users of older versions. This link takes you to a different version of the Ansible documentation. Use the version selection on the left or your browser back button to return to this version of the documentation.
.. seealso:: .. seealso::

Write Preview
Loading…
Cancel
Save