This section describes the Ansible and ``ansible-base`` releases. Ansible is the package that most users install. ``ansible-base`` is primarily for developers.
For Ansible version 2.10 or later, the major release is maintained for one release cycle. When the next release comes out (for example, 2.11), the older release (2.10 in this example) is no longer maintained.
This table links to the release notes for each major Ansible release. These release notes (changelogs) contain the dates and significant changes in each minor release.
``ansible-base`` is developed and released on a flexible 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. See :ref:`roadmaps` for upcoming release details.
``ansible-base`` has a graduated maintenance structure that extends to three major releases.
For more information, read about the :ref:`development_and_stable_version_maintenance_workflow` or
see the chart in :ref:`release_schedule` for the degrees to which current releases are maintained.
If you are using a release of ``ansible-base`` that is no longer maintained, we strongly
encourage you to upgrade as soon as possible in order to benefit from the
latest features and security fixes.
Older, unmaintained versions of ``ansible-base`` can contain unfixed security
vulnerabilities (*CVE*).
You can refer to the :ref:`porting guides<porting_guides>` for tips on updating your Ansible
playbooks to run on newer versions.
You can download the ``ansible-base`` release from `<https://releases.ansible.com/ansible/>`_.
..note::``ansible-base`` maintenance continues for 3 releases. Thus the latest release receives
security and general bug fixes when it is first released, security and critical bug fixes when
the next ``ansible-base`` version is released, and **only** security fixes once the follow on to that version is released.
.._release_schedule:
This table links to the release notes for each major ``ansible-base`` release. These release notes (changelogs) contain the dates and significant changes in each minor release.
Collection updates (new modules, plugins, features and bugfixes) will always be integrated in what will become the next version of Ansible. This work is tracked within the individual collection repositories.
We generate 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.
Since Ansible is a package of individual collections, the deprecation cycle depends on the collection maintainers. We recommend the collection maintainers deprecate a feature in one Ansible major version and do not remove that feature for one year, or at least until the next major Ansible version. For example, deprecate the feature in 2.10.2, and do not remove the feature until 2.12.0. Collections should use semantic versioning, such that the major collection version cannot be changed within an Ansible major version. Thus the removal should not happen before the next major Ansible release. This is up to each collection maintainer and cannot be guaranteed.
