Hi all, we might have caused a bit of trouble with the major release.
^
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.
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 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.
@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?
I just noticed that cloud.common requires ansible-core < 2.19 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.)
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.)
@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
