* 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)
@ -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.