Roadmap and breaking changes

Get Help
, ,
1

Hello,
New to forum and looking for ansible roadmap, more future ansible 14 as 13 just got out.
I saw [Vote ended on 2025-09-18] Ansible 13 roadmap - #9 by felixfontein (Ansible 13 roadmap by mariolenz · Pull Request #3000 · ansible/ansible-documentation · GitHub) or [Vote ended on 2025-11-27] Ansible 14 roadmap - #7 by mariolenz (Ansible 14 roadmap by mariolenz · Pull Request #3201 · ansible/ansible-documentation · GitHub) but seems more a placeholder at this point as no detail on breaking changes and other.
ansible-core 2.21 (Ansible-core 2.21 — Ansible Core Documentation; Ansible-core 2.21 Porting Guide — Ansible Core Documentation) has a schedule but no feature/breaking change either.
Also New Ansible Meetup Strategy is here! or New Release: ansible-core v2.20.1
Considering ansible 12 and 13 had their share of breaking/noisy changes with ALLOW_BROKEN_CONDITIONALS and INJECT_FACTS_AS_VARS, how can roles maintainer be better informed and prepared to this kind of change?
It’s a pity those two changes did not make to ansible-lint first (New INJECT_FACTS_AS_VARS deprecation in 2.20 is not reported by linter · Issue #4857 · ansible/ansible-lint · GitHub RFE: rule for injected ansible var usage (e.g. not using ansible_facts) · ansible/ansible-lint · Discussion #1611 · GitHub Disallow (and rewrite) injected variables · ansible/ansible-lint · Discussion #3457 · GitHub) and better, ansible-lint autofix (Autofix - Ansible Lint Documentation) which would make review of numerous roles less painful (and playbooks. and vars folders).
Thanks

2

Just a few notes,

is not really a breaking change, just a warning about deprecation of the default value of a setting, which can still be set explicitly. The change of the default value won’t happen for a few versions and I would not even call that ‘breaking’ when it happens. The main problem is that play/role authors were relying on this setting having a specific value and it was not apparent. The core team has avoided adding any settings that affect the play/role content in this way, specifically to avoid such issues … but we cannot rewrite the past that easily.

The simplest way for a role to handle a required value for ANY setting they depend on is to use the config lookup in an assert to enforce that requirement. Relying on any setting to be set to a specific value should always have such guards, it does not matter if it was the default or not.

This itself is not a breaking change, but a way to allow for ‘suspect’ conditionals to work after a bug fix that removed ambiguity from conditionals. This fixes many cases of ‘accidental’ true/false evaluations of expressions. These incorrect evaluations might have allowed your play to 'just work’TM, but it is not good that this was done by accident and not explicitly, hence the change. That said, we are aware of how big of an onus it can be to rewrite content, which is why this setting (and others) were added, to defer/delay rewrites to when it is more convenient.

IMHO bug fixes are ‘breaking changes’ by definition, ones we find acceptable, but not everyone agrees that a certain behavior is a bug or not. Sometimes a ‘breaking change’ is not discovered until it hits users, tests cannot cover every possible usage, specially ones that were not intended nor imagined by the authors, so it is not always possible to publish them ahead of time.

3

The Ansible community package roadmap does not and will likely never contain breaking changes related to the content (ansible-core and collections), only related to the packaging of it (if there are some). So these are not “placeholders” but the actual roadmaps.

If you want to know about breaking changes, I’d suggest to look at deprecations in earlier releases (these show up in the porting guides of these releases as well). Planned breaking changes usually are preceeded by deprecations in earlier versions.

4

To explain why the Ansible Community Package will likely never contain breaking changes on the roadmap for the content, that is ansible-core and collections:

  1. For ansible-core it should be documented in their roadmap and wouldn’t make sense to duplicate this in ours.
  2. For collections, there’s the problem that during the release process we include the latest stable versions of the collections. At some point, there’s a feature freeze (I think usually beta1) where we won’t add any newer (backwards incompatible, that is containing breaking changes) releases. Although this date is usually well-defined, we cannot foresee what collection versions will be the latest by then.
1 Like
5

Thanks for the inputs.
My definition of breaking change is that either now, either sooner or later, my code will break if left as is (including config). Deprecation warnings are indication of something that is planned to break at some point, I believe.
I’m all for better quality, security, resiliency, performance and so on.

My main goal is to keep track of those changes to anticipate them, ideally regroup them, so I and other users can avoid to do review all theirs roles, playbooks, variables and else too many times. imho, ideal target is once a year, two max, more than that for a volunteer contributor is too demanding. possibly too for work.
I would think bug attached to deprecation are longer term issue usually with larger constraints than standard bug and that’s why they are not just patched/fixed immediately.

I saw recently more deprecation warnings but unclear how to fix.

I believe that those like above are more in ansible-core. not asking to duplicate.

Some instructions to locate deprecated code and how to fix it would be really helpful.
Like linters do args - Ansible Lint Documentation
And ideally deprecation is included in linter early on, first as warning (before or when deprecation warning added), and next error (before full deprecation).