If a collection only does the first three steps, we’re in a bad situation: the users only find out about the deprecation / rename when reading the changelog / porting guide, but they do not get runtime deprecation warnings.
We discussed that at today’s community meeting, and came up with a proposal, namely to adopt these two points:
If a collection is renamed, the new collection is only added to Ansible if the old one has been replaced by a new major version that consists out of deprecated redirects.
The deprecated redirect collection stays for two major releases, unless the SC votes to keep it for longer.
Just to clarify: The removal after the two next major releases would not need a vote. It’s automatically OK to do this if no one starts a vote to remove the collection sooner or later.
I guess the wrinkle here is that CI will fail in ansible-build-data during the time between the new major version that depends on the renamed collection and the addition of the new collection to the package config.
Hmm, that’s actually a good point. It’s only a problem if the new one is actually added as a dependency to the old one, but that’s generally a good idea.
We would have to add a ignore entry for that major version to avoid the CI failures. Thus we have more manual tracking from our side; I guess it’s still worth it to avoid even worse situations, though.