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

Backport/2.9/docs release (#64173)

Browse Source 
* 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
4 changed files with 23 additions and 33 deletions
Show Stats Download Patch File Download Diff File

14
docs/docsite/rst/community/development_process.rst
Unescape Escape View File

@ -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>`
* 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 `core documentation project <https://github.com/ansible/ansible/projects/27>`_
@ -225,7 +225,7 @@ We do **not** backport features.
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
``git remote`` named ``upstream``. If you do not use
a ``git remote`` named ``upstream``, adjust the instructions accordingly.
@ -238,7 +238,7 @@ We do **not** backport features.
::
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
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]``
against the ``stable-2.8`` branch
#. Submit the pull request for ``backport/2.9/[PR_NUMBER_FROM_DEVEL]``
against the ``stable-2.9`` branch
#. 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
@ -264,7 +264,7 @@ We do **not** backport features.
.. 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
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

4
docs/docsite/rst/conf.py
Unescape Escape View File

@ -143,9 +143,9 @@ html_context = {
'github_version': 'devel/docs/docsite/rst/',
'github_module_version': 'devel/lib/ansible/modules/',
'current_version': version,
'latest_version': '2.8',
'latest_version': '2.9',
# 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
),
}

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

@ -11,7 +11,7 @@ Release and maintenance
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
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
============================== =================================================
devel In development (2.9 unreleased, trunk)
`2.8 Release Notes`_ Maintained (security **and** general bug fixes)
`2.7 Release Notes`_ Maintained (security **and** critical bug fixes)
`2.6 Release Notes`_ Maintained (security fixes)
devel In development (2.10 unreleased, trunk)
`2.9 Release Notes`_ Maintained (security **and** general bug fixes)
`2.8 Release Notes`_ Maintained (security **and** critical bug 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.4 Release Notes`_ 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)
<2.5 Unmaintained (end of life)
============================== =================================================
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
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: 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.6 Release Notes:
.. _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.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:
.. _methods:
@ -105,12 +95,12 @@ releases of Ansible, there can sometimes be exceptions for critical issues.
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.
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.
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'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
~~~~~~~~~~~~~~~~~~
@ -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),
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.
For modules/plugins, we keep the documentation after the removal for users of older versions.

2
hacking/build_library/build_ansible/command_plugins/plugin_formatter.py
Unescape Escape View File

@ -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
# 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
MODULEDIR = os.path.abspath(os.path.join(

Write Preview
Loading…
Cancel
Save