---
# System prepended metadata

title: 'Ansible Release Management: Cadence, Versioning, and Process'

---

# Ansible Release Management: Cadence, Versioning, and Process

Ansible now maintains two coordinated release streams: **ansible-core** (the engine and core modules) and the **Ansible Community Package** (the Ansible 2.10+ “umbrella” package that bundles ansible-core plus Collections). These run on different versioning schemes and lifecycles.  

The community package adopted **Semantic Versioning** at 2.10 (with versions like `3.0.0`, `4.0.0`, etc.), whereas **ansible-core** continues the classic `X.Y.Z` numbering inherited from Ansible 2.9 and before.  

- Major **ansible-core** releases (the `Y` in `X.Y.Z`) occur roughly twice per year, and are **not guaranteed backward-compatible** to the previous major.  
- Community-package releases then follow each new ansible-core, bundling the latest compatible Collections.  

---

## Release Cycle

The release cycle works roughly as follows:

1. Cut a new ansible-core major (e.g., `2.11`, `2.12`, …).  
   - At this point, the new core and the two previous core majors enter a **maintenance phase**.  
2. Impose a freeze on new Collection versions for the community package.  
3. Produce release candidate(s) for the Ansible community package.  
4. Publish the new community major (e.g., **Ansible 4.0.0** on **ansible-core 2.11**).  
   - After this, only the newest community major is supported.  

In parallel:  
- Regular **patch releases** happen about every four weeks.  
- Security/bugfix patches are provided for the last three ansible-core majors.  
- Minor point releases are published for the current community package.  

-> Example: After **Ansible 4.0.0** (community) is released, only `4.x` will get updates. Older `3.x` becomes **EOL**. Occasionally, a final maintenance release may be issued for an EOL version.  

---

## Versioning Rules

- **Community Package** → uses **strict semver** (`major.minor.patch`)  
  - Minor bumps only introduce backwards-compatible Collection updates.  
- **ansible-core** → uses classic `X.Y.Z`  
  - `X` = internal architecture (e.g., 1 vs 2)  
  - `Y` = release number (not guaranteed compatible to previous Y).  

Patch (`Z`) releases on both streams carry only **bug and security fixes**.  
- ansible-core patches follow a **fixed 4-week schedule**.  
- Each new ansible-core release also brings rolling support for the latest Python versions, while older versions are phased out.  

---

## Release Process

The release process is **highly automated** but coordinated across multiple components:

- **[ansible-build-data](https://github.com/ansible-community/ansible-build-data)** → central repo tracking:  
  - Included Collections (`ansible.in` list)  
  - Release dates  
  - Blocker issues  

- Release engineers use:  
  - **antsibull-build** (to assemble the community package from Collections + ansible-core)  
  - **antsibull-changelog** (to generate changelogs from repo fragments)  

- Release artifacts:  
  - Built as `ansible-x.y.z` wheels and tarballs  
  - Uploaded to **PyPI** via `twine`  
  - Git tags pushed to repos  

- Announcements:  
  - Posted on the **Ansible Forum (News & Announcements)** and **Matrix** (via “Bullhorn” bot).  
  - Documentation (ansible-documentation repo) and **Porting Guides** updated in lockstep.  

---

## Execution Environment (EE) Images

The **Execution Environment (EE) images** follow a cadence aligned with ansible-core:

- Two community EE images are published:  
  - `community-ee-minimal` → only ansible-core  
  - `community-ee-base` → ansible-core + a small set of core Collections (e.g., `ansible.posix`, `ansible.utils`, `ansible.windows`).  

- These are **Fedora-based container images**, versioned by included ansible-core version (e.g., `2.18.9-1` contained ansible-core `2.18.9`).  

- Each EE release announcement includes:  
  - Fedora base image  
  - ansible-core version  
  - Collection versions  
  - Image digests  
  - `docker pull` / `podman pull` commands for GHCR.io tags.  

- EE images are rebuilt whenever a new ansible-core is released, and announcements are posted to the Ansible Forum.  

---

## Communication

Communication is a **key pillar** of the release process:

- Public Forum → especially *News & Announcements*  
- Matrix chat rooms → `#release-management`, `#community`, etc.  
- Docs → Official **Release and Maintenance** documentation.  
- Each major release has a **roadmap** and **porting guide**  

In short, **ansible-core** and the **Ansible Community Package** are released on **synchronized but distinct cadences**, with clear versioning rules and automated tooling (**antsibull-build**, **antsibull-changelog**, **ansible-build-data**) tying everything together.  

---

## Sources

- [Releases and Maintenance — Ansible Community Docs](https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html)  
- [ansible-build-data repo](https://github.com/ansible-community/ansible-build-data)  
- [Manual Release Process](https://ansible.readthedocs.io/projects/ansible-build-data/release-process/)  
- [antsibull-changelog repo](https://github.com/ansible-community/antsibull-changelog)  
- [EE Release Announcement 2.18.9-1](https://forum.ansible.com/t/release-announcement-ansible-community-execution-environment-base-and-minimal-2-18-9-1/44478)  
- [EE Images Availability Guide](https://forum.ansible.com/t/execution-environments-getting-started-guide-community-ee-images-availability/1341)  
- [EE Release Announcement 2.19.1-1](https://forum.ansible.com/t/release-announcement-ansible-community-execution-environment-base-and-minimal-2-19-1-1-latest/44479)  

---

✍️ [*Abhay Dandge*](https://www.linkedin.com/in/abhaydandge/)
