Survey on improving the versioning of ansible-lint

[ssbarnea]

Ansible DevTools considered improving the release versioning for our projects for quite some time. With ansible-lint being the most popular project, that would be a good point to start with.

While we followed a SemVer variation that was also based on ansible-core approach, we faced some problems. No way to guess the age of a release by looking at the number.

We don't want to drop the SemVer and we identified at least two alternatives which extend it to include more information. We also observed more and more projects switching to one of these, which is a sign that they probably work well.

So if we are to release a major version in November 2023, should it be using:

• v23.1.0 if using CalVer YY.RELEASE.PATCH, basically the version scheme used by pip, the python package installer. If the project does not make any breaking changes, only the patch will be increased.
• v23.11.0 if using CalVer YY.MONTH.PATCH, same versioning used by [Ubuntu](https://wiki.ubuntu.com/Releases0 . It has the advantage of mentioning the month but the disadvantage of not telling how many major versions released a project had during the year.
• v6.22.0 if we keep using current SemVer

Background info

Ansible-lint kept v6.0.0 was released in March 2022 and the lastest version v6.21.1 was released in October 2024. In between there were 21 major releases and 68 releases in total. We will never be able to support a big list of versions and if someone reports an issue with v6.8.2 we have no way to guess how old that one is.

The project matured and we expect to have a considerable lower number of major releases. If possible, we might even aim to have just two per year, but realistically it will likely be a little bit more, like one major version every quarter.

[sean-m-sullivan]

Do not like the month one, maybe match the major version to ansible major version instead of year, so its more like semVer. I do get the have no clue how old it is, But not sure how much of a problem it is on your end.

[ssbarnea]

That is indeed a very good suggestion. Nothing prevents us from re-using the ansible-core version number.

What is still not clear to me is to which version of ansible do we refer to: either the oldest one we do support, or the last one that we tested with?

[felixfontein]

I voted something else since I would prefer a change to real semantic versioning.

[ssbarnea]

@felixfontein I am curious how far we were from a real SemVer with linter, at least with 6.x releases. If you have few minutes, can you look on how many of the 21 MINOR releases made under 6.x should have being counted as major instead? I am curious, especially as this being a CLI, there are lots of gray areas.

[felixfontein]

Well, you claimed that ansible-lint uses ansible-core's versioning model and not 'real' semver, which implies breaking changes also for 6.x.0 releases. I couldn't find any mentioned in the changelogs; but I found minor changes in a bugfix release (https://github.com/ansible/ansible-lint/releases/tag/v6.0.2) and I know of one bugfix release (https://github.com/ansible/ansible-lint/releases/tag/v6.20.2) containing a breaking change (#3798 broke workflows using the GHA action). I guess the latter wasn't intentional though, as it was labelled as a bugfix in the changelog.

[mr1chter]

I would add that you count those 21 releases as major yourself in the poll description. So clearly they are major from your perspective.

Going through them quickly, I would also add "Remove progressive mode" of 6.16.0 as "definitely major". I think new mandatory rules count as well, but someone else could maybe disagree.

ofc, it would help to have a small "what is a breaking change" guideline in the dev docs somewhere.

[mr1chter]

No way to guess the age of a release by looking at the number.

In which way is this an issue? Why is this so important? (You only mentioned this as the driver for the decision)
Read the background now, sorry. But still, I think it makes sense to only support the latest version (or latest version in RHEL) to circumvent this problem. Or just ask to reproduce in the latest version, e.g. with virtualenv.

I just now noticed the versioning change and found this ticket (why was the versioning change not mentioned in the changelog??).
It's also not clear to me why the YEAR.MONTH layout was chosen even though it was the least popular option (No one voted for it). Or is it the YEAR.RELEASE option? (There is no mention of why to start with .2)

Imho Semver is important for a linter because new lints break CIs and it's great to know as a user when an update is "safe" and when we expect work with an update.

I would also challenge your definition of "minor" changes in this context (as taken from the same Releases page). dropping supported python versions is a breaking, even major change. But I can see why this would be a smaller issues for you, since e.g. the ansible-community packages do the same.

Maybe I'm just expecting the wrong things, coming from a java background where this is different.