The netapp.storagegrid collection looks unmaintained / abandoned, it has:
For the record, someone says that the collection is still maintained. Well, let’s see what they say about the failing / not running CI and that it doesn’t test with ansible-core > 2.13.
I’d like to vote on removing this collection from Ansible 11 since it looks unmaintained. The vote will end 2024-02-17.
The vote ended today. 9 steering committee members voted, and all are in favor of removing netapp.storagegrid from Ansible 11. No one voted to keep the collection. This means we’ve reached the quorum and the vote is accepted.
There were no votes from the community, neither in favor of nor against it.
@SteeringCommittee Does this count as One or multiple maintainers step up, or return, to clean up the collection's state?. I should think so, but I also think there are still some problems:
Anyway, are they even using semver? After 20.11.0 they’ve released 21.6.0. Isn’t semver a requirement? I’m a bit confused about their versioning at the moment.
Isn’t semver a requirement?
Looks like it’s a MUST. I remember there were talks about it in the context of the netapp collections years ago but i don’t remember any details… @felixfontein maybe you have any memories on that? Anyway, we should do something: 1. ask them to comply 2. change MUST to SHOULD. 3. accept another versioning convention, like that one with YY-*…
They’ve dropped support for ansible (core) < 2.14 in a minor release
Isn’t it OK if it doesn’t necessarily imply breaking stuff? e.g. when we just stop testing against it? If in their case it breaks stuff, that’s definitely not acceptable:)
I think this isn’t documented somewhere and there are different opinions. I tend to the view that dropping support is a breaking change because might mean users can’t update to a new minor (or even bugfix) release without also updating ansible-core to a new major version.
But, as I’ve said, I think there are different opinions on this.
Semver is a MUST from our side since Ansible itself is semver, so we must be able to rely on collections to also follow semver.
Removing support for ansible-core versions is something where multiple opinions exist. Unfortunately ansible-galaxy collection install does not handle supported ansible-core versions similar to pip handling supported Python versions, so I would argue that dropping ansible-core support is a breaking change. I know that plenty of other folks (both from RH and community) see it differently. Also there’s a difference between not supporting a specific ansible-core version (i.e. no longer test against it, so accidental incompatibilities are possible), and actively not supporting it (by actively removing code that’s needed to support it). I guess the former is a gray area…
In any case, since these requirements are for building Ansible, dropping support for older ansible-core versions (that are no longer supported by the supported Ansible releases) should not really concern us, since that isn’t a breaking change for Ansible itself - it ships a modern enough ansible-core.
So from that point, I would say semver is a MUST, but dropping support for older ansible-core versions is a kind of acceptable semver violation, at least for inclusion in Ansible.
I think that one counts, but there’s still point 3:
There have been concrete results made by new maintainers (for example, CI has been fixed, the collection has been released, pull request authors have got meaningful feedback).
Failing CI isn’t a good sign (of course it depends on why it fails).
I don’t think semver says that you need to release 21.0.0 before you release 21.6.0, though it’s not very common. Maybe they synchronize version numbers with something else? Or they use calver for new major releases, and then switch to regular semver? I do remember there has been a discussion about their versioning scheme, but I don’t remember the details…
It doesn’t look like the code is bad. Looks more like a problem in their CI workflow for me. But why did they commit and release if the CI fails? I don’t like it…
Hi, I’ve been working on bringing this collection back in line to avoid it being removed and will try to address some of these outstanding questions.
Previously the various NetApp collections used CalVer (YY.MM.PATCH) until SemVer was enforced. I don’t fully remember the details, but to avoid issues with collection upgrades, “21” remained as the Major version number. It’s consistent across all NetApp Ansible collections I believe.
I agree regarding the failing CI workflows - currently discussing with another maintainer and will work on clearing the errors. My main priority was ensuring it passed with 2.14 and 2.15.