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.