# Roadmap and breaking changes **URL:** \ **Category:** Get Help\ **Tags:** documentation, community-wg, ansible-lint\ **Created:** [January 18, 2026, 10:45pm UTC](https://forum.ansible.com/t/roadmap-and-breaking-changes/45127 "2026-01-18T22:45:12Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![juju4](https://avatars.discourse-cdn.com/v4/letter/j/dec6dc/32.png) [@juju4](https://forum.ansible.com/u/juju4)\ **Post date:** [January 18, 2026, 10:45pm UTC](https://forum.ansible.com/t/roadmap-and-breaking-changes/45127/1 "2026-01-18T22:45:12Z")
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](https://forum.ansible.com/t/vote-ended-on-2025-09-18-ansible-13-roadmap/44367/9) ([Ansible 13 roadmap by mariolenz · Pull Request #3000 · ansible/ansible-documentation · GitHub](https://github.com/ansible/ansible-documentation/pull/3000/files)) or [[Vote ended on 2025-11-27] Ansible 14 roadmap - #7 by mariolenz](https://forum.ansible.com/t/vote-ended-on-2025-11-27-ansible-14-roadmap/44778/7) ([Ansible 14 roadmap by mariolenz · Pull Request #3201 · ansible/ansible-documentation · GitHub](https://github.com/ansible/ansible-documentation/pull/3201/files)) 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](https://docs.ansible.com/projects/ansible-core/devel/roadmap/ROADMAP_2_21.html); [Ansible-core 2.21 Porting Guide — Ansible Core Documentation](https://docs.ansible.com/projects/ansible-core/devel/porting_guides/porting_guide_core_2.21.html)) has a schedule but no feature/breaking change either. Also [New Ansible Meetup Strategy is here!](https://forum.ansible.com/t/new-ansible-meetup-strategy-is-here/44999) or [New Release: ansible-core v2.20.1](https://forum.ansible.com/t/new-release-ansible-core-v2-20-1/44976) 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](https://github.com/ansible/ansible-lint/issues/4857) [RFE: rule for injected ansible var usage (e.g. not using ansible\_facts) · ansible/ansible-lint · Discussion #1611 · GitHub](https://github.com/ansible/ansible-lint/discussions/1611) [Disallow (and rewrite) injected variables · ansible/ansible-lint · Discussion #3457 · GitHub](https://github.com/ansible/ansible-lint/discussions/3457)) and better, ansible-lint autofix ([Autofix - Ansible Lint Documentation](https://docs.ansible.com/projects/lint/autofix/)) which would make review of numerous roles less painful (and playbooks. and vars folders). Thanks ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [January 19, 2026, 12:02am UTC](https://forum.ansible.com/t/roadmap-and-breaking-changes/45127/2 "2026-01-19T00:02:01Z")
Just a few notes, > [@juju4](#): > > INJECT\_FACTS\_AS\_VARS 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. > [@juju4](#): > > ALLOW\_BROKEN\_CONDITIONALS 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. ---
**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:** [January 19, 2026, 5:54am UTC](https://forum.ansible.com/t/roadmap-and-breaking-changes/45127/3 "2026-01-19T05:54:13Z")
> [@juju4](#): > > 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](https://forum.ansible.com/t/vote-ended-on-2025-09-18-ansible-13-roadmap/44367/9) ([Ansible 13 roadmap by mariolenz · Pull Request #3000 · ansible/ansible-documentation · GitHub](https://github.com/ansible/ansible-documentation/pull/3000/files)) or [[Vote ended on 2025-11-27] Ansible 14 roadmap - #7 by mariolenz](https://forum.ansible.com/t/vote-ended-on-2025-11-27-ansible-14-roadmap/44778/7) ([Ansible 14 roadmap by mariolenz · Pull Request #3201 · ansible/ansible-documentation · GitHub](https://github.com/ansible/ansible-documentation/pull/3201/files)) but seems more a placeholder at this point as no detail on breaking changes and other. 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. ---
**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:** [January 19, 2026, 5:12pm UTC](https://forum.ansible.com/t/roadmap-and-breaking-changes/45127/4 "2026-01-19T17:12:17Z")
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. ---
**Author:** ![juju4](https://avatars.discourse-cdn.com/v4/letter/j/dec6dc/32.png) [@juju4](https://forum.ansible.com/u/juju4)\ **Post date:** [January 25, 2026, 8:21pm UTC](https://forum.ansible.com/t/roadmap-and-breaking-changes/45127/5 "2026-01-25T20:21:49Z")
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. - `[DEPRECATION WARNING]: Importing 'to_native' from 'ansible.module_utils._text' is deprecated. This feature will be removed from ansible-core version 2.24. Use ansible.module_utils.common.text.converters instead.` at top of playbook execution and `ansible -m setup`… Seen on [Deprecation warnings in ansible-core 2.20](https://forum.ansible.com/t/deprecation-warnings-in-ansible-core-2-20/44741) or [`ansible.posix.authorized_key` deprecation warning from import of to\_native · Issue #695 · ansible-collections/ansible.posix · GitHub](https://github.com/ansible-collections/ansible.posix/issues/695) - `The internal "vars" dictionary is deprecated.` Also [The internal "vars" dictionary is deprecated · Issue #86434 · ansible/ansible · GitHub](https://github.com/ansible/ansible/issues/86434) - `[DEPRECATION WARNING]: Importing '_AnsibleActionDone' is deprecated.` 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](https://docs.ansible.com/projects/lint/rules/args/#special-cases) And ideally deprecation is included in linter early on, first as warning (before or when deprecation warning added), and next error (before full deprecation).