ansible core documentation release checklist

Ansible-core release overview

Our work for an upcoming release starts when a new stable branch is created for the upcoming ansible-core release. Since we have to touch multiple releases, this means that:

• Most changes start in the devel branch and get backported to the new stable branch for the upcoming release.
• Some changes to support the version switcher have to be backported to all maintained releases.
• One set of changes has to happen in the newly EOL’d branch.

To make this clear in the instructions below, we’ll use the following conventions:

• stable-NEW - reflects the newly created stable branch for the upcoming release.
• stable-NEW-1 and stable-NEW-2 - reflects the two prior releases that will continue to be maintained.
• stable-EOL - the release before stable-NEW-2 that will go EOL once stable-NEW is released.

So for example, for ansible-core 2.14 release:

• stable-NEW is stable-2.14(the newly created branch)
• stable-NEW-1 is stable-2.13, and stable-NEW-2 is stable-2.12
• stable-EOL is stable-2.11.

Checklist steps before release occurs

1. Review changelogs in stable-NEW in the changelogs/changelog.rst file. This is just a general scan to ensure it's a well-formed RST file. We do not edit changelogs as it requires finding the appropriate fragment and editing that instead of this generated file. This generated file may not appear until the first release candidate is created.
2. Review the core porting guide (at docs/docsite/rst/porting_guide/porting_guide_NEW.rst) as follows:
   1. Ensure it links to stable-NEW changelogs reviewed in the prior step.

• include ansible-core in Release Status Grid and ensure maintenance/eol releases listed accurately. Include links to changelogs. Typically, the oldest maintained release goes EOL.

See also

Ansible documentation release checklists Return to docs wiki