# CfgMgmtCamp 2026 discussion (3/12): Big breaking changes come with no explanation of why they are happening

**URL:** <https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-3-12-big-breaking-changes-come-with-no-explanation-of-why-they-are-happening/45290>\
**Category:** Project Discussions\
**Tags:** cfgmgmgtcamp, breaking-changes, collections, ansible-core\
**Created:** [February 7, 2026, 8:58pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-3-12-big-breaking-changes-come-with-no-explanation-of-why-they-are-happening/45290 "2026-02-07T20:58:16Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![nitzmahone](https://avatars.discourse-cdn.com/v4/letter/n/c5a1d2/32.png) [@nitzmahone](https://forum.ansible.com/u/nitzmahone)\
**Post date:** [February 14, 2026, 12:40am UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-3-12-big-breaking-changes-come-with-no-explanation-of-why-they-are-happening/45290/5 "2026-02-14T00:40:12Z")

</div>

> [@kastl-ars](#):
>
> a small overview page showing the current deprecations (including in which version the thing will be removed) and **which versions is needed to use the new behaviour**.

Hmmm, I like parts of this a lot- the way we currently manually document deprecations only in the changelog for the version it first appears in makes this horrible for users to assemble, but would also be an absolute nightmare for us to maintain manually…

Referencing our push to make long-running non-atomic code tasks declarative/SSOT over on [8/12](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-8-12-instant-ansible-test-target-updates-without-announcements/45295/4), and thinking about the granular warning control stuff we’ve been kicking around, this seems like something we should be able to generate pretty easily directly from the code as part of that work using the same extraction mechanisms that the deprecation sanity tests use. I’d be happy to trade more detailed inline declarative descriptions of deprecations for manually crafted changelog/porting guide entries on those things- especially if we could tie it in with the “externally linked documentation in error/deprecation/warning” stuff.

I’m less sure about how workable the second half of that ask might be to generate, but might be doable in, e.g., the non-versioned community docs build, pulling from the same declarative metadata we’d cough up for the “all pending deprecations in this release”.

---

_[View the full topic](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-3-12-big-breaking-changes-come-with-no-explanation-of-why-they-are-happening/45290)._