Release and maintenance

    Ansible has a graduated support structure that extends to three major releases.For more information, read about the Development and stable version maintenance workflow orsee the chart in for the degrees to which current releases are supported.

    If you are using a release of Ansible that is no longer supported, we stronglyencourage you to upgrade as soon as possible in order to benefit from thelatest features and security fixes.

    Older, unsupported versions of Ansible can contain unfixed securityvulnerabilities (CVE).

    You can refer to the porting guides for tips on updating your Ansibleplaybooks to run on newer versions.

    This table links to the release notes for each major release. These release notes (changelogs) contain the dates and significant changes in each minor release.

    You can download the releases from .

    Note

    Ansible support lasts for 3 releases. Thus the latest Ansible release receivessecurity and general bug fixes when it is first released, security and critical bug fixes whenthe next Ansible version is released, and only security fixes once the follow on to that version is released.

    The Ansible community develops and maintains Ansible on GitHub.

    Ansible provides bugfixes and security improvements for the most recent major release. The previousmajor release will only receive fixes for security issues and critical bugs. Ansible only appliessecurity fixes to releases which are two releases old. This work is tracked on thestable-<version> git branches.

    The fixes that land in supported stable branches will eventually be releasedas a new version when necessary.

    Note that while there are no guarantees for providing fixes for unsupportedreleases of Ansible, there can sometimes be exceptions for critical issues.

    Since Ansible 2.5, we have generated changelogs based on fragments. Here is the generated changelog for 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.

    Creating New Fragments

    Create a new file with a unique and descriptive name in changelogs/fragments/ that ends in .yaml such as

    A single changelog fragment may contain multiple sections but most will only contain one section. Here are the valid sections and a description of each:

    • major_changes
    • Major changes to Ansible itself. Generally does not include module or plugin changes.
    • Minor changes to Ansible, modules, or plugins. This includes new features, new parameters added to modules, or behavior changes to existing parameters.
    • deprecated_features
    • Features that have been deprecated and are scheduled for removal in a future release.
    • removed_features
    • Features that were previously deprecated and are now removed.
    • bugfixes
    • Fixes that resolve issues. If there is a specific issue related to this bugfix, add a link in the changelog entry.
    • known_issues
    • Known issues that are currently not fixed or will not be fixed.

    Most changelog entries will be bugfixes or minor_changes. When writing a changelog entry that pertains to a particular module, start the entry with - [module name] - and include a link to the related issue if one exists. Here are some examples:

    1. minor_changes:
    2.   - lineinfile - add warning when using an empty regexp (https://github.com/ansible/ansible/issues/29443)

    Commit the changelog fragment and include it with the pull request.

    Older versions logged changes in branches at stable-<version>/CHANGELOG.md. For example, here is the changelog for 2.4 on GitHub.

    This provides the Ansible community the opportunity to test Ansible and reportbugs or issues they might come across.

    Ansible tags the first release candidate (RC1) which is usually scheduledto last five business days. The final release is done if no major bugs orissues are identified during this period.

    If there are major problems with the first candidate, a second candidate willbe tagged (RC2) once the necessary fixes have landed.This second candidate lasts for a shorter duration than the first.If no problems have been reported after two business days, the final release isdone.

    More release candidates can be tagged as required, so long as there arebugs that the Ansible core maintainers consider should be fixed before thefinal release.

    While there is a pending release candidate, the focus of core developers andmaintainers will on fixes towards the release candidate.

    Merging new features or fixes that are not related to the release candidate maybe delayed in order to allow the new release to be shipped as soon as possible.

    Sometimes we need to remove a feature, normally in favor of a reimplementation that we hope does a better job.To do this we have a deprecation cycle. First we mark a feature as ‘deprecated’. This is normally accompanied with warningsto the user as to why we deprecated it, what alternatives they should switch to and when (which version) we are scheduledto 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.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.

    • Guidelines for Ansible core contributors and maintainers
    • Testing strategies
    • Ansible Community Guide
    • Community information and contributing
    • Ansible release tarballs
    • Development Mailing List
    • Mailing list for development topics

    • ansible IRC chat channel