-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Description
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.ymlin themainbranch will always contain the version of the next major or minor release. It will be updated right after a release.version_addedneeds 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-xbranches.- Shortly (usually a few hours) before a new major release,
stable-xis branched.
- Shortly (usually a few hours) before a new major release,
- New features can be backported to the current
stable-xrelease branch afterx.0.0, and until the last minor release forstable-xhas been released.- Once a new major version is released, there will be no more minor releases for previous
stable-xbranches. - 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
mainbranch, the three lateststable-xbranches receive backports. - New features must not break backwards compatibility!
- Once a new major version is released, there will be no more minor releases for previous
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.