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 andansible -m setup…
Seen on Deprecation warnings in ansible-core 2.20 or `ansible.posix.authorized_key` deprecation warning from import of to_native · Issue #695 · ansible-collections/ansible.posix · GitHubThe internal "vars" dictionary is deprecated.
Also The internal "vars" dictionary is deprecated · Issue #86434 · ansible/ansible · GitHub[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
And ideally deprecation is included in linter early on, first as warning (before or when deprecation warning added), and next error (before full deprecation).