I wanted to take a few minutes and write something down in public that I’ve described a number of times in the past.
What versioning scheme does ansible-core use?
It’s not really any named versioning scheme that I am aware of. The versioning in ansible-core is historical. It’s not semver, and at the moment there are no active plans to change the versioning scheme.
What is the X
in X.Y.Z
?
The X
here doesn’t imply any form of compatibility. The X
represents the internal architecture of ansible-core
.
v1
can be best described as the internal architecture revolving aroundansible.runner.Runner
as the “execution” enginev2
can be best described as the internal architecture revolving around theTaskQueueManager
,PlayIterator
, and the strategy as the “execution” engine
X
doesn’t imply anything about the scope of the changes.
What is the Y
in X.Y.Z
?
Every ~6 months, in May and November ansible-core releases a new Major release. This is denoted by the Y
in the X.Y.Z
version scheme.
As such, versions like 2.9.0
, 2.10.0
, 2.11.0
, 2.16.0
and 2.19.0
are all major releases. X.Y.0
releases do not carry any guarantee of 100% backwards compatibility with the version before it. Some may be more or less impactful based on the scope of the work for the release. Check porting guides for changes that may necessitate user intervention.
What is the Z
in X.Y.Z
?
This is the patch version. ansible-core operates on a 4 week patch schedule. The Z
release of a major version will include bugfixes and security fixes as outlined in the support matrix:
0-6 months after release: Bug fixes and security fixes
6-12 months after release: Critical bug fixes and security fixes
12-18 months after release: Security fixes only
(AAP and RHEL downstream extended support not outlined here)