They’re both part of the Ansible Community Package. What should we do with those collections?
I think there are three possibilities:
Replace the old with the new collections (not a good idea because this would be breaking).
Add the new collections and remove the old ones in a later ACP major release.
Deprecate and remove the collections completely.
I tend to 3, and to do it ASAP. Maybe even deprecate them in 14 and remove them from 15. Especially since they didn’t do a new major release. Renaming a minor release and not doing a new major release for this violates SemVer IMHO.
If they are both in the package, and the change is a rename only, I don’t think it would be fair to make them resubmit to get into the package again. So I would say 2 (for whatever that is worth )
Edit: I do see now your point about this being a minor release. I think they’re communication or planning with ACP could’ve been better, but they did the name change is a reasonable way IMO
But at the end of the day, pinning and keeping those collections indefinitely isn’t a solution. I think we need to do something about this. I guess we’ll do either 2 or 3.
On the one hand, option 2 would be better for users. On the other hand, this means that we allow collections that are part of the ACP to do stupid, non-SemVer changes. And I don’t like this… actually, this means we’re working around their non-SemVer changes.
As I’ve said, I can live with option 2. I’m open to both options. Let’s see what others have to say about this.
The releases violated the inclusion requirements by adding a new dependency and removing content in a new minor release (without making sure the dependency is added ot the package first). This is a breaking change (for ACP, not for the collection itself since it adds the dependency) and not acceptable.
There is an established process of renaming a collection that’s part of the Ansible community package (namely Ansible Package Release Management), which wasn’t followed here. It explicitly asks for a new major release.
There’s also another problem: since the repository has been renamed/moved to another organization, both the original collection and the renamed collection now use the same repository and the same version numbers. This makes it impossible to satisfy the inclusion requirements that collections need to be tagged.
For that reason, option 2 is technically not possible right now. Option 1 would be possible, but would be very unfriendly to our users.