Skip to content

Describe general Ansible major version release schedule #2490

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 4 commits into
base: devel
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions docs/docsite/rst/roadmap/ansible_roadmap_index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,37 @@ You can submit feedback on the current roadmap by creating a :ref:`community top

Visit the :ref:`Ansible communication guide<communication>` for details on how to join and use Ansible communication platforms.

.. _ansible_general_major_release_schedule:

General release schedule for a new major Ansible release
--------------------------------------------------------

The release of a new major Ansible version (``X.0.0``) is coupled to a new major ansible-core release (``2.Y.0``). This section describes the general schedule. A more specific schedule will be mentioned on each major version's roadmap page (see below). If ansible-core releases are delayed, the Ansible release schedule is usually updated to adhere to this general release schedule.

The generic release schedule of a new major Ansible version ``X.0.0`` can be split up into three phases:

1. When ansible-core 2.Y.0 **beta** releases are published, there will be one Ansible X.0.0 **alpha** release roughly one day after the corresponding ansible-core beta release.

1. When ansible-core 2.Y.0 **rc (release candidate)** releases are published, there will be one Ansible X.0.0 **alpha** release roughly one day after the corresponding ansible-core rc release.

1. When ansible-core 2.Y.0 is generally made available (usually on a Monday), the following schedule will happen from that day on:

1. The day of the ansible-core 2.Y.0 day is the last day for collections to make backwards incompatible releases that will be accepted into Ansible X.0.0. This includes adding new collections to Ansible X.0.0; from now on new collections have to wait for X.1.0 or later.

1. Ansible's feature freeze will happen on the next day (usually Tuesday), and the first (and usually only) Ansible X.0.0 **beta** release (b1) will be made.

1. One week later (again on Tuesday), the first Ansible X.0.0 **rc (release candidate)** will be released. For this release, only bugfix updates for collections are accepted from the versions included in the Ansible X.0.0 b1.

1. If no release blockers showed up by Friday of the same week, Ansible X.0.0 will be made generally available on Tuesday of the following week (thus one week after X.0.0 rc1).

1. If there have been release blockers, a second release candidate release, Ansible X.0.0 rc2, will happen on Tuesday of the following week (one week after X.0.0 rc1), and the general availability will usually happen one week after that (again on a Tuesday).

1. Four weeks after the ansible-core 2.Y.0 release, and 1-2 weeks after the Ansible X.0.0 release, ansible-core 2.Y.1 will be released on (usually) a Monday, and one day later (usually Tuesday) there will be the Ansible X.1.0 release.

Note that the schedule might be extended with further Ansible X.0.0 beta or X.0.0 release candidate releases if circumstances require additional time, such as when larger changes in ansible-core require more testing in collections.
The above schedule (especially with X.0.0 being generally available one week after X.0.0 rc1) is an optimistic schedule, which usually works fine, but might not always provide enough time.


.. toctree::
:maxdepth: 1
:glob:
Expand Down