Renaming collections that are part of the Ansible community package

Project Discussions
, ,
1

Right now we have a process of renaming collections that are part of Ansible (GitHub - ansible-community/ansible-build-data: Holds generated but persistent results from building the ansible community package). This process has a problem:

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.

Also there’s the question of how long the deprecated redirects should be part of the community package. (I just noticed that GitHub - ansible-community/ansible-build-data: Holds generated but persistent results from building the ansible community package answers that, but we apparently forgot about that - see the discussion in Ibm.spectrum_virtualize deprecated / renamed and Add metadata to indicate which collections are unmaintained / deprecated / will be removed by felixfontein · Pull Request #450 · ansible-community/ansible-build-data · GitHub)

We discussed that at today’s community meeting, and came up with a proposal, namely to adopt these two points:

  1. 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.

  2. The deprecated redirect collection stays for two major releases, unless the SC votes to keep it for longer.

What do you think?

5 Likes
2

I was at today’s meeting and agree with the proposal above.

1 Like
3

I support the proposal

1 Like
4

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.

Correct?

1 Like
5

Yes, and not even a discussion. Only if we want something else than two major releases we have to discuss it, and reach consensus / vote on it.

3 Likes
6

If nobody objects, I’ll start a vote somewhen during the next days.

2 Likes
7

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.

8

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.

9

On the other hand, instead of adding the ignore entry, we can also simply directly add the new collection. So I don’t think this is a problem.

If there are no more comments / objections, I’ll start a vote.

10

What’s the current situation about renaming a collection, or even deprecating a collection in favor of another one that’s (possibly) not 100% compatible? Do we have a process on this yet?

I’m asking because community.digitalocean looks unmaintained / abandoned and that they want to replace it with digitalocean.cloud.

I’m not sure if Migrating Ansible content to a different collection really works always. After all, people might want to stop working on one collection without moving everything to a new collection. Or having modules in the new collection that basically provide the same functionality, but are not 100% compatible with old ones.

11

It sounds like the correct solution is for digitalocean.cloud to independently apply for inclusion in the Ansible package. If community.digitalocean is indeed unmaintained, we can remove it using the normal process, regardless of what happens with digitalocean.cloud.

https://github.com/ansible-community/ansible-build-data/?tab=readme-ov-file#renaming-a-collection says:

  • baz.bam A.B.C must be compatible to foo.bar a.b.c up to renaming plugins. No options must be renamed without backwards compatible aliases, and no defaults or semantics changed.

digitalocean.cloud is described as “a grounds-up rewrite of the community.digitalocean collection,” so I do not think the renaming process is appropriate here.

1 Like