Backport/2.9/docs release (#64173)

* docs: update to latest 3 versions (#64109)

(cherry picked from commit 409545825f)

* update too old version to 2.4 (#64167)

(cherry picked from commit c63ef6d911)

* update backport instructions to use stable-2.9 (#64168)

(cherry picked from commit f264e9cfca)

* [Doc-Release-2.9] update release and maintenance page for 2.9 (#64166)
* only 2.4 and earlier used the old changelog system

(cherry picked from commit 3f808d9ed6)
pull/64274/head
Alicia Cozine 5 years ago committed by GitHub
parent e6751a2d2a
commit d55f7a0d26
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -18,7 +18,7 @@ If you want to follow the conversation about what features will be added to Ansi
* the :ref:`Ansible Release Schedule <release_and_maintenance>` * the :ref:`Ansible Release Schedule <release_and_maintenance>`
* various GitHub `projects <https://github.com/ansible/ansible/projects>`_ - for example: * various GitHub `projects <https://github.com/ansible/ansible/projects>`_ - for example:
* the `2.8 release project <https://github.com/ansible/ansible/projects/30>`_ * the `2.10 release project <https://github.com/ansible/ansible/projects/39>`_
* the `network bugs project <https://github.com/ansible/ansible/projects/20>`_ * the `network bugs project <https://github.com/ansible/ansible/projects/20>`_
* the `core documentation project <https://github.com/ansible/ansible/projects/27>`_ * the `core documentation project <https://github.com/ansible/ansible/projects/27>`_
@ -225,7 +225,7 @@ We do **not** backport features.
These instructions assume that: These instructions assume that:
* ``stable-2.8`` is the targeted release branch for the backport * ``stable-2.9`` is the targeted release branch for the backport
* ``https://github.com/ansible/ansible.git`` is configured as a * ``https://github.com/ansible/ansible.git`` is configured as a
``git remote`` named ``upstream``. If you do not use ``git remote`` named ``upstream``. If you do not use
a ``git remote`` named ``upstream``, adjust the instructions accordingly. a ``git remote`` named ``upstream``, adjust the instructions accordingly.
@ -238,7 +238,7 @@ We do **not** backport features.
:: ::
git fetch upstream git fetch upstream
git checkout -b backport/2.8/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.8 git checkout -b backport/2.9/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.9
#. Cherry pick the relevant commit SHA from the devel branch into your feature #. Cherry pick the relevant commit SHA from the devel branch into your feature
branch, handling merge conflicts as necessary: branch, handling merge conflicts as necessary:
@ -253,10 +253,10 @@ We do **not** backport features.
:: ::
git push origin backport/2.8/[PR_NUMBER_FROM_DEVEL] git push origin backport/2.9/[PR_NUMBER_FROM_DEVEL]
#. Submit the pull request for ``backport/2.8/[PR_NUMBER_FROM_DEVEL]`` #. Submit the pull request for ``backport/2.9/[PR_NUMBER_FROM_DEVEL]``
against the ``stable-2.8`` branch against the ``stable-2.9`` branch
#. The Release Manager will decide whether to merge the backport PR before #. The Release Manager will decide whether to merge the backport PR before
the next minor release. There isn't any need to follow up. Just ensure that the automated the next minor release. There isn't any need to follow up. Just ensure that the automated
@ -264,7 +264,7 @@ We do **not** backport features.
.. note:: .. note::
The choice to use ``backport/2.8/[PR_NUMBER_FROM_DEVEL]`` as the The choice to use ``backport/2.9/[PR_NUMBER_FROM_DEVEL]`` as the
name for the feature branch is somewhat arbitrary, but conveys meaning name for the feature branch is somewhat arbitrary, but conveys meaning
about the purpose of that branch. It is not required to use this format, about the purpose of that branch. It is not required to use this format,
but it can be helpful, especially when making multiple backport PRs for but it can be helpful, especially when making multiple backport PRs for

@ -143,9 +143,9 @@ html_context = {
'github_version': 'devel/docs/docsite/rst/', 'github_version': 'devel/docs/docsite/rst/',
'github_module_version': 'devel/lib/ansible/modules/', 'github_module_version': 'devel/lib/ansible/modules/',
'current_version': version, 'current_version': version,
'latest_version': '2.8', 'latest_version': '2.9',
# list specifically out of order to make latest work # list specifically out of order to make latest work
'available_versions': ('latest', '2.7', '2.6', 'devel'), 'available_versions': ('latest', '2.8', '2.7', 'devel'),
'css_files': ('_static/ansible.css', # overrides to the standard theme 'css_files': ('_static/ansible.css', # overrides to the standard theme
), ),
} }

@ -11,7 +11,7 @@ Release and maintenance
Release cycle Release cycle
````````````` `````````````
Ansible is developed and released on a flexible 4 months release cycle. Ansible is developed and released on a flexible six month release cycle.
This cycle can be extended in order to allow for larger changes to be properly 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. implemented and tested before a new release is made available.
@ -38,18 +38,13 @@ This table links to the release notes for each major release. These release note
============================== ================================================= ============================== =================================================
Ansible Release Status Ansible Release Status
============================== ================================================= ============================== =================================================
devel In development (2.9 unreleased, trunk) devel In development (2.10 unreleased, trunk)
`2.8 Release Notes`_ Maintained (security **and** general bug fixes) `2.9 Release Notes`_ Maintained (security **and** general bug fixes)
`2.7 Release Notes`_ Maintained (security **and** critical bug fixes) `2.8 Release Notes`_ Maintained (security **and** critical bug fixes)
`2.6 Release Notes`_ Maintained (security fixes) `2.7 Release Notes`_ Maintained (security fixes)
`2.6 Release Notes`_ Unmaintained (end of life)
`2.5 Release Notes`_ Unmaintained (end of life) `2.5 Release Notes`_ Unmaintained (end of life)
`2.4 Release Notes`_ Unmaintained (end of life) <2.5 Unmaintained (end of life)
`2.3 Release Notes`_ Unmaintained (end of life)
`2.2 Release Notes`_ Unmaintained (end of life)
`2.1 Release Notes`_ Unmaintained (end of life)
`2.0 Release Notes`_ Unmaintained (end of life)
`1.9 Release Notes`_ Unmaintained (end of life)
<1.9 Unmaintained (end of life)
============================== ================================================= ============================== =================================================
You can download the releases from `<https://releases.ansible.com/ansible/>`_. You can download the releases from `<https://releases.ansible.com/ansible/>`_.
@ -60,19 +55,14 @@ You can download the releases from `<https://releases.ansible.com/ansible/>`_.
.. Comment: devel used to point here but we're currently revamping our changelog process and have no .. 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 link to a static changelog for devel _2.6: https://github.com/ansible/ansible/blob/devel/CHANGELOG.md
.. _2.9 Release Notes:
.. _2.9: https://github.com/ansible/ansible/blob/stable-2.9/changelogs/CHANGELOG-v2.9.rst
.. _2.8 Release Notes: .. _2.8 Release Notes:
.. _2.8: https://github.com/ansible/ansible/blob/stable-2.8/changelogs/CHANGELOG-v2.8.rst .. _2.8: https://github.com/ansible/ansible/blob/stable-2.8/changelogs/CHANGELOG-v2.8.rst
.. _2.7 Release Notes: https://github.com/ansible/ansible/blob/stable-2.7/changelogs/CHANGELOG-v2.7.rst .. _2.7 Release Notes: https://github.com/ansible/ansible/blob/stable-2.7/changelogs/CHANGELOG-v2.7.rst
.. _2.6 Release Notes: .. _2.6 Release Notes:
.. _2.6: https://github.com/ansible/ansible/blob/stable-2.6/changelogs/CHANGELOG-v2.6.rst .. _2.6: https://github.com/ansible/ansible/blob/stable-2.6/changelogs/CHANGELOG-v2.6.rst
.. _2.5 Release Notes: https://github.com/ansible/ansible/blob/stable-2.5/changelogs/CHANGELOG-v2.5.rst .. _2.5 Release Notes: https://github.com/ansible/ansible/blob/stable-2.5/changelogs/CHANGELOG-v2.5.rst
.. _2.4 Release Notes:
.. _2.4: https://github.com/ansible/ansible/blob/stable-2.4/CHANGELOG.md
.. _2.3 Release Notes: https://github.com/ansible/ansible/blob/stable-2.3/CHANGELOG.md
.. _2.2 Release Notes: https://github.com/ansible/ansible/blob/stable-2.2/CHANGELOG.md
.. _2.1 Release Notes: https://github.com/ansible/ansible/blob/stable-2.1/CHANGELOG.md
.. _2.0 Release Notes: https://github.com/ansible/ansible/blob/stable-2.0/CHANGELOG.md
.. _1.9 Release Notes: https://github.com/ansible/ansible/blob/stable-1.9/CHANGELOG.md
.. _support_life: .. _support_life:
.. _methods: .. _methods:
@ -105,12 +95,12 @@ releases of Ansible, there can sometimes be exceptions for critical issues.
Changelogs Changelogs
~~~~~~~~~~ ~~~~~~~~~~
Older versions logged changes in ``stable-<version>`` branches at ``stable-<version>/CHANGELOG.md``. For example, here is the changelog for 2.4_ on GitHub. Since Ansible 2.5, we have generated changelogs based on fragments. Here is the generated changelog for 2.9_ as an example. When creating new features or fixing bugs, create a changelog fragment describing the change. A changelog entry is not needed for new modules or plugins. Details for those items will be generated from the module documentation.
We now generate changelogs based on fragments. Here is the generated changelog for 2.8_ as an example. When creating new features or fixing bugs, create a changelog fragment describing the change. A changelog entry is not needed for new modules or plugins. Details for those items will be generated from the module documentation.
We've got :ref:`examples and instructions on creating changelog fragments <changelogs_how_to>` in the Community Guide. We've got :ref:`examples and instructions on creating changelog fragments <changelogs_how_to>` in the Community Guide.
Older versions logged changes in ``stable-<version>`` branches at ``stable-<version>/CHANGELOG.md``. For example, here is the changelog for `2.4 <https://github.com/ansible/ansible/blob/stable-2.4/CHANGELOG.md>`_ on GitHub.
Release candidates Release candidates
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
@ -157,7 +147,7 @@ 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), The cycle is normally across 4 feature releases (2.x.y, where the x marks a feature release and the y a bugfix release),
so the feature is normally removed in the 4th release after we announce the deprecation. 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. For example, something deprecated in 2.7 will be removed in 2.11, assuming we don't jump to 3.x before that point.
The tracking is tied to the number of releases, not the release numbering. 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. For modules/plugins, we keep the documentation after the removal for users of older versions.

@ -54,7 +54,7 @@ from ..jinja2.filters import do_max, documented_type, html_ify, rst_fmt, rst_ify
# if a module is added in a version of Ansible older than this, don't print the version added information # if a module is added in a version of Ansible older than this, don't print the version added information
# in the module documentation because everyone is assumed to be running something newer than this already. # in the module documentation because everyone is assumed to be running something newer than this already.
TOO_OLD_TO_BE_NOTABLE = 2.3 TOO_OLD_TO_BE_NOTABLE = 2.4
# Get parent directory of the directory this script lives in # Get parent directory of the directory this script lives in
MODULEDIR = os.path.abspath(os.path.join( MODULEDIR = os.path.abspath(os.path.join(

Loading…
Cancel
Save