# Adjust Ansible 12 release schedule

**URL:** <https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507>\
**Category:** Project Discussions\
**Tags:** release-management, ansible, community-wg\
**Created:** [April 3, 2025, 8:22pm UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507 "2025-04-03T20:22:13Z")\
**Posts on this page:** 12\
**Page:** 2

<div class="post-metadata">

**Author:** ![KB-perByte](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/kb-perbyte/32/541_2.png) [@KB-perByte](https://forum.ansible.com/u/KB-perByte)\
**Post date:** [August 20, 2025, 4:16pm UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507/21 "2025-08-20T16:16:12Z")

</div>

Hi all, we might have caused a bit of trouble with the major release.

> [@Ansible.netcommon broken with Ansible Core 2.19.0](https://forum.ansible.com/t/ansible-netcommon-broken-with-ansible-core-2-19-0/44043/27):
>
> @felixfontein @mariolenz The concern is real. But we need to bump the dependency to make sure that the platform collection always resolves aka pulls in the correct version of netcommon, to support all versions of ansible-core that we are testing with that is 2.15 - 2.19 and devel, milestone. Now, Core ≤ 2.18 white_check_mark netcommon works fine up to v8.0.1white_check_mark Platform collections (e.g., cisco.ios, cisco.nxos, arista.eos) are not impacted Core = 2.19 cross_mark ne…

^  
Based on this, we have always followed a cycle of major releases when a breaking change is fixed or a dependency update is addressed. In this case, it was both.  
Having received feedback from the Steering Committee Members, and the team being on a clock to make it to the downstream EE build. We had to make a decision. Whether to make a major release or a minor one. But given the regression that was handled, we decided that a major release makes the most sense for us. We are open to updating our practices with any updated policies present.

As per the releases that happened, none of them consider any breaking change from a user standpoint.

Regards.

---

<div class="post-metadata">

**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 20, 2025, 6:00pm UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507/22 "2025-08-20T18:00:50Z")

</div>

Hi, @KB-perByte, thank you for providing additional context and for getting the fixes out to the netcommon collection. To clarify, the issue here is that we don’t update collection major versions in the community package after our feature freeze. After feature freeze starts with the beta1 release, we continue allowing semver patch version (x.y. **Z** ) releases for bugfixes from collections until the release candidate. We already made an exception to allow new minor releases (x. **Y**.z) pass the feature freeze to accommodate the network collections, but now we are in a position where we need to disregard more of our policies to include these new major versions so late in the release cycle so we don’t ship broken collections in the release. That’s not great, especially when this could have possibly been avoided.

When making scheduling/versioning decisions for collections included in the community package in the future, I would suggest looking at the Ansible roadmaps in [Ansible Roadmap — Ansible Community Documentation](https://docs.ansible.com/ansible/devel/roadmap/ansible_roadmap_index.html) so we can make sure that the Ansible package gets released on time and doesn’t include broken collections. The Steering Committee is also working separately on clarifying how we communicate this to collection maintainers, so let us know if there is any way we can make the requirements surrounding the release schedule clearer.

---

<div class="post-metadata">

**Author:** ![KB-perByte](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/kb-perbyte/32/541_2.png) [@KB-perByte](https://forum.ansible.com/u/KB-perByte)\
**Post date:** [August 21, 2025, 11:35am UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507/23 "2025-08-21T11:35:27Z")

</div>

@gotmax23 got it, thank you for considering the exceptions for us.  
And we plan to do our yearly major/ deprecation releases in sync with the **ansible\_roadmap**.  
This was an unexpected regression, which triggered the need for the dependency update.

As folks said that this major release can be avoided, we were not ready to risk the practices we followed all this time around, considering collections having major releases. But moving forward, I would work with my team to revise our release strategy and consider dependency updates in a minor release, if that is advised.

Can we help with any set of information that makes you consider the major release’d collections?

---

<div class="post-metadata">

**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 21, 2025, 6:26pm UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507/24 "2025-08-21T18:26:19Z")

</div>

I just noticed that cloud.common [requires ansible-core \< 2.19](https://github.com/ansible-collections/cloud.common/blob/main/meta/runtime.yml#L2) since version 5.0.0, released on June 25th. We’ve been including this version in Ansible 12 pre-releases since 12.0.0a7. (Previous versions didn’t explicitly require ansible-core \< 2.19.)

There has been [an attempt to fix this](https://github.com/ansible-collections/cloud.common/pull/189), but last activity on the PR has been on June 13. There has been no activity by maintainers in the issues [for ansible-core 2.19 compatibility](https://github.com/ansible-collections/cloud.common/issues/166) and [a similar one](https://github.com/ansible-collections/cloud.common/issues/165) since then. (@mariolenz asked two weeks ago whether there are news: no reaction.)

This collection is a dependency of vmware.vmware\_rest, so if we remove cloud.common now, we also have to remove vmware.vmware\_rest. It definitely would be more preferable if this gets fixed instead of having to remove these two collections. Or is this a problem that doesn’t matter too much? (I don’t use either of the collections so I don’t know what it affects.)

[@SteeringCommittee](https://forum.ansible.com/groups/steeringcommittee) [@release-managers](https://forum.ansible.com/groups/release-managers) What do you think?

---

<div class="post-metadata">

**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 22, 2025, 5:12pm UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507/25 "2025-08-22T17:12:00Z")

</div>

> [@felixfontein](#):
>
> This collection is a dependency of vmware.vmware\_rest, so if we remove cloud.common now, we also have to remove vmware.vmware\_rest. It definitely would be more preferable if this gets fixed instead of having to remove these two collections. Or is this a problem that doesn’t matter too much? (I don’t use either of the collections so I don’t know what it affects.)

For the record, I’ve opened an issue to discuss [dropping the dependency on cloud.common for vmware.vmware\_rest](https://github.com/ansible-collections/vmware.vmware_rest/issues/619).

@gundalow Not to put too fine a point on this, but somehow it feels like we run into lots of problems with collections maintained by Red Hat recently. `cloud.common`, the network collections… I think we should improve this 😏

---

<div class="post-metadata">

**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 27, 2025, 7:57pm UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507/26 "2025-08-27T19:57:30Z")

</div>

Since vmware.vmware\_rest is currently preparing to work without cloud.common and remove the dependency, and should soon have a new release, we can safely remove cloud.common from Ansible 12 since a) it doesn’t support ansible-core 2.19, and b) no other collection included in Ansible 12 depends on it. I’ve prepared a PR to remove it: [Remove cloud.common from Ansible 12 by felixfontein · Pull Request #593 · ansible-community/ansible-build-data · GitHub](https://github.com/ansible-community/ansible-build-data/pull/593). (It will fail CI until a new version of vmware.vmware\_rest has been released.)

---

<div class="post-metadata">

**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 28, 2025, 5:18pm UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507/27 "2025-08-28T17:18:10Z")

</div>

I hope we’ll see a new `vmware.vmware_rest` release dropping the requirement on `cloud.common` [soon](https://github.com/ansible-collections/vmware.vmware_rest/pull/622#issuecomment-3234168225) 😃

---

<div class="post-metadata">

**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 30, 2025, 11:57am UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507/28 "2025-08-30T11:57:34Z")

</div>

Now that `vmware.vmware_rest` 4.9.0 is out and [doesn’t depend on cloud.common anymore](https://galaxy.ansible.com/ui/repo/published/vmware/vmware_rest/dependencies/?version=4.9.0), how do you think we should proceed?

I guess the next release will include `vmware.vmware_rest` 4.9.0 and drop `cloud.common`, but should it be another beta or do we want to go straight to rc1?

---

<div class="post-metadata">

**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 30, 2025, 12:56pm UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507/29 "2025-08-30T12:56:36Z")

</div>

I wanted to ask that myself, but didn’t got around to do it 🙂 Since I think the blockers are gone by now (once `cloud.common` is gone), I’m fine with doing a rc1 release on next Tuesday. Then we might be able to do 12.0.0 GA in the week after that (together with Ansible 11.10.0, and maybe also ansible-core 2.19.2, depending on whether the 2.19 schedule is adjusted to the general 2.1x schedule by then or not).

[@SteeringCommittee](https://forum.ansible.com/groups/steeringcommittee) [@release-managers](https://forum.ansible.com/groups/release-managers) what do you think?

---

<div class="post-metadata">

**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 30, 2025, 1:28pm UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507/30 "2025-08-30T13:28:14Z")

</div>

+1 on rc1 next week. It’s about time we release 12.0.0 and this would speed things up.

---

<div class="post-metadata">

**Author:** ![briantist](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/briantist/32/130_2.png) [@briantist](https://forum.ansible.com/u/briantist)\
**Post date:** [September 1, 2025, 4:47am UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507/31 "2025-09-01T04:47:04Z")

</div>

I have no specific opinion (abstain I guess)

---

<div class="post-metadata">

**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 2, 2025, 6:41pm UTC](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507/32 "2025-09-02T18:41:40Z")

</div>

[Ansible 12.0.0rc1 has been released](https://forum.ansible.com/t/44407)! Thanks @TKeller for doing the release!

[Previous page](https://forum.ansible.com/t/adjust-ansible-12-release-schedule/41507.md?page=1)