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/)