# Renaming collections that are part of the Ansible community package **URL:** \ **Category:** Project Discussions\ **Tags:** rename, community-wg, collections\ **Created:** [August 28, 2024, 7:43pm UTC](https://forum.ansible.com/t/renaming-collections-that-are-part-of-the-ansible-community-package/8150 "2024-08-28T19:43:14Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [August 28, 2024, 7:43pm UTC](https://forum.ansible.com/t/renaming-collections-that-are-part-of-the-ansible-community-package/8150/1 "2024-08-28T19:43:15Z")
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](https://github.com/ansible-community/ansible-build-data?tab=readme-ov-file#renaming-a-collection)). 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](https://github.com/ansible-community/ansible-build-data?tab=readme-ov-file#renaming-a-collection) answers that, but we apparently forgot about that - see the discussion in [Ibm.spectrum\_virtualize deprecated / renamed](http://forum.ansible.com/t/8119) and [Add metadata to indicate which collections are unmaintained / deprecated / will be removed by felixfontein · Pull Request #450 · ansible-community/ansible-build-data · GitHub](https://github.com/ansible-community/ansible-build-data/pull/450#pullrequestreview-2263779527.)) 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? ---
**Author:** ![gotmax23](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gotmax23/32/106_2.png) [@gotmax23](https://forum.ansible.com/u/gotmax23)\ **Post date:** [August 28, 2024, 9:13pm UTC](https://forum.ansible.com/t/renaming-collections-that-are-part-of-the-ansible-community-package/8150/2 "2024-08-28T21:13:08Z")
I was at today’s meeting and agree with the proposal above. ---
**Author:** ![Andersson007](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/andersson007/32/89_2.png) [@Andersson007](https://forum.ansible.com/u/Andersson007)\ **Post date:** [August 29, 2024, 8:30am UTC](https://forum.ansible.com/t/renaming-collections-that-are-part-of-the-ansible-community-package/8150/3 "2024-08-29T08:30:12Z")
I support the proposal ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [August 29, 2024, 1:57pm UTC](https://forum.ansible.com/t/renaming-collections-that-are-part-of-the-ansible-community-package/8150/4 "2024-08-29T13:57:20Z")
> [@felixfontein](#): > > 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. Correct? ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [August 29, 2024, 5:56pm UTC](https://forum.ansible.com/t/renaming-collections-that-are-part-of-the-ansible-community-package/8150/5 "2024-08-29T17:56:32Z")
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. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [September 8, 2024, 9:09pm UTC](https://forum.ansible.com/t/renaming-collections-that-are-part-of-the-ansible-community-package/8150/6 "2024-09-08T21:09:33Z")
If nobody objects, I’ll start a vote somewhen during the next days. ---
**Author:** ![gotmax23](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gotmax23/32/106_2.png) [@gotmax23](https://forum.ansible.com/u/gotmax23)\ **Post date:** [September 9, 2024, 8:54pm UTC](https://forum.ansible.com/t/renaming-collections-that-are-part-of-the-ansible-community-package/8150/7 "2024-09-09T20:54:11Z")
> [@felixfontein](#): > > 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. 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. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [September 9, 2024, 9:07pm UTC](https://forum.ansible.com/t/renaming-collections-that-are-part-of-the-ansible-community-package/8150/8 "2024-09-09T21:07:33Z")
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. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [September 25, 2024, 3:46pm UTC](https://forum.ansible.com/t/renaming-collections-that-are-part-of-the-ansible-community-package/8150/9 "2024-09-25T15:46:34Z")
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. ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [October 1, 2025, 4:41pm UTC](https://forum.ansible.com/t/renaming-collections-that-are-part-of-the-ansible-community-package/8150/10 "2025-10-01T16:41:30Z")
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](https://github.com/ansible-collections/community.digitalocean) looks unmaintained / abandoned and that they want to replace it with [digitalocean.cloud](https://github.com/digitalocean/ansible-collection). I’m not sure if [Migrating Ansible content to a different collection](https://docs.ansible.com/ansible/latest/dev_guide/developing_collections_migrating.html) 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. ---
**Author:** ![gotmax23](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gotmax23/32/106_2.png) [@gotmax23](https://forum.ansible.com/u/gotmax23)\ **Post date:** [October 1, 2025, 10:01pm UTC](https://forum.ansible.com/t/renaming-collections-that-are-part-of-the-ansible-community-package/8150/11 "2025-10-01T22:01:51Z")
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](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`](https://galaxy.ansible.com/ui/repo/published/community/digitalocean/) collection,” so I do not think the renaming process is appropriate here.