Including Ansible Collections that do not follow semantic versioning

[tadeboro]

While reviewing the netapp.cloudmanager Ansible Collection, I learned that some of the collections do not follow semantic versioning. The collection in question has more information about versioning in the pinned issue.

I described some of the problems using the custom versioning scheme brings in my review comment.

Right now, if someone would ask me "does collection that does not follow semantic versioning still qualifies for inclusion in community Ansible package", I would say no. But I would like to hear from other people what they think about this topic.

[felixfontein]

IMO following semantic versioning is an absolute MUST which we should absolutely require. (I do not mean that we should kick collections out that accidentally include a new feature in a bugfix release, or a breaking change in a minor release - I mean collections which use a versioning system that is not compatible to semver, like netapp.cloudmanager.)

While in some cases (of versioning schemes) it would be possible to adjust the dependency management in antsibull so that it is possible to accomodate them:

1. if we try to be strict (like in this case, fix the YY.M(M) part for an Ansible major release), we'll have an outdated version of the collection for most of the release cycle, forcing the user to install newer versions manually, which will cause trouble on upgrading Ansible (as the manually installed collection will mask the one coming with newer Ansible versions);
2. if we are not strict and simply apply the same semver-based rules (as for all other collections), we either risk including breaking changes (as netapp.cloudmanager can have them all over the year), or we have to clear new versions manually. The latter is IMO not acceptable for the community package.

So if netapp.cloudmanager wants to stick to their versioning system, I would always vote against inclusion in Ansible (without looking at any other aspect of that collection).

[tadeboro]

To make things even more complicated, a few of the collections that are already part of the ansible python package also use the date-based versioning scheme. So this is not a new problem, it just flew under the radar because those collections were grandfathered into the ansible python package.

[felixfontein]

@tadeboro this is very unfortunate, since they have been made aware of the rules a long time ago: ansible-collections/netapp#50 ansible-collections/netapp#51 ansible-collections/netapp#52

[carchi8py]

@felixfontein @tadeboro way back in 2019 when we met with Redhat (@thedoubl3j ). We were told that the version we were using for our collection was fine, and we've been using this versioning now with customers for 2+ years. Based on conversations with Redhat in our monthly meeting we were told we would just need to create a page linked off our Readme describing how we do versioning (ansible-collections/netapp#93 (comment)), which is here. Right now we are hearing both yes your version is ok, and no your versioning is not ok from Redhat at the same time.

We have 1000's of customer who already uses these modules, who have gone through the training @schmots1 gives almost weekly to the customer. We really don't want to change this and confuse customers.

[carchi8py]

Hey @felixfontein and @tadeboro . We had our stand-up morning with the entire team this morning. And i got everyone on board to switch to the version sematic versioning mentioned here , here https://semver.org/
So instead of YY.MM.path we will go we will switch to Major.Minor.Patch

I want to confirm that the plan below will work for you guys
right now we are on version 21.04.0
21 will now be our major version.
4 will be our minor version

We release new features each month so for the next 8 releases, the version will match the date (assuming we keep the cadence). When January hit, the version will be 21.13.0
21 will only get updated to 22 if there is a major API change.

Does this work with you guys?

[felixfontein]

@carchi8py that would be really awesome! :) (I can also understand that you're not happy that you got different information from different people / groups in RH; I have no connection to AH or the people responsible for that, but my assumption was always that collections should use semver, and for collections included in the Ansible community package it is a strong requirement since the whole package is supposed to be semantically versioned, which only works in a mostly automated fashion if all collections it includes stick to semver.)

[lonico]

I updated our pinned issue accordingly. We are now using semantic versioning.
ansible-collections/netapp#93

[tadeboro]

Thank you, @carchi8py and @lonico, for your work on this issue!

While the proposed release process and versioning scheme are still not fully semantic versioning compliant (semver only allows incrementing numbers by one and resetting them to 0), the proposed changes do makes sure that Ansible users will get the updates in a timely manner while at the same time being able to prevent breakage by adding an upper-bound based on a major version.

I will update my collection reviews appropriately, but I will leave this as a next meeting topic so we can discuss things a bit and maybe add a bit more documentation about how the versioning should be done, how to set up repositories so that not all collections share the same tags, ...

Thank you again for persevering!

[tadeboro]

We discussed the issues around semantic versioning and concluded that:

1. We will keep the semantic versioning requirement for included collections.
2. The NetApp Ansible collections satisfy the requirements for inclusion as far as the versioning is concerned.

During the discussion, we also realized that we are not sure if incrementing major, minor, or patch numbers for more than one is actually in contradiction with the semantic versioning conventions. The example from semver.org seems to suggest we should increment things by one:

A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

But the text is less clear. But since this does not change the inclusion outcome, we left that problem for the future us.