Skip to content

Releasing, Versioning and Deprecation (2/N) #11482

@felixfontein

Description

@felixfontein

This issue continues #582.

Introduction

This issue describes how and when community.general is released, and to announce updates to the release/versioning schedule. The next section (Next releases) is always updated to contain the next versions to be released. Other changes to this first post are always announced by separate posts in this issue.

Next releases

Release When Supported ansible-core Supported Controller Supported Target
13.0.0 May 2026 2.18+ Python 3.11+ Python 3.8+
Powershell 5.1+
12.5.0 around March 23rd 2.17+ Python 3.10+ Python 3.7+
Powershell 5.1+
11.4.6 around March 23rd 2.16+ Python 3.10+ Python 2.7, 3.6+
Powershell 5.1+
10.7.9 when necessary 2.15+ Python 3.9+ Python 2.7, 3.5+
PowerShell 3 - 5.1+

Check Python minimum requirements for ansible-core.

Releasing schedule for major and minor versions

Minor or bugfix releases usually happen in a four-week schedule aligned to releases of the Ansible community package.

  • The current (N) major release gets new minor releases regularly with new bugfixes, features, and new plugins.
  • The previous (N-1) major release gets new bugfix releases regularly.
  • The major release before that (N-2) only gets serious bugfixes and security fixes, and releases are made when necessary.

In exceptional situations, additional bugfix releases will be made outside the four-week schedule. If the Ansible release schedule is adjusted (one or more weeks earlier or later), the community.general release schedule is usually adjusted as well. This is usually announced in this issue.

New major releases happen before feature freeze of a new major Ansible community package release. The release schedule of new major Ansible releases can be found here: https://docs.ansible.com/projects/ansible/devel/roadmap/ansible_roadmap_index.html

Supported ansible-core and Python versions

Every new major community.general release supports all ansible-core releases that have not been End of Life for more than a few weeks when the community.general X.0.0 release happened, and all future ansible-core releases that get released during the first year after its release.

Every community.general release supports all Python versions that are supported by at least one of the ansible-core releases it supports.

A summary of supported ansible-core and Python releases can be found in the table above.

Versioning

  • galaxy.yml in the main branch will always contain the version of the next major or minor release. It will be updated right after a release.
  • version_added needs to be used for every new feature and module/plugin, and needs to coincide with the next minor/major release version. (This will eventually be enforced by CI.)

Branching

  • Releasing minor and major releases is done from stable-x branches.
    • Shortly (usually a few hours) before a new major release, stable-x is branched.
  • New features can be backported to the current stable-x release branch after x.0.0, and until the last minor release for stable-x has been released.
    • Once a new major version is released, there will be no more minor releases for previous stable-x branches.
    • From then on, only bugfixes are allowed for ~6 months (backporting to the current two major releases).
    • After that, only major bugfixes security fixes are allowed for another ~6 months (backporting to the current three major releases).
    • This means that next to the main branch, the three latest stable-x branches receive backports.
    • New features must not break backwards compatibility!

Deprecation

  • Deprecations are done by version number (not by date).
  • New deprecations can be added during every minor release, under the condition that they do not break backwards compatibility.
  • Deprecations are expected to have a deprecation cycle of at least 2 major versions (that means at least 1 year). Maintainers can use a longer deprecation cycle if they want to support the old code for that long.

Information for contributors

Check out CONTRIBUTING.md.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions