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
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.