# CfgMgmtCamp 2026 discussion (5/12): Supported ansible-core versions when installing collections **URL:** \ **Category:** Project Discussions\ **Tags:** cfgmgmgtcamp, ansible-galaxy, version, ansible-core\ **Created:** [February 7, 2026, 8:59pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-5-12-supported-ansible-core-versions-when-installing-collections/45292 "2026-02-07T20:59:34Z")\ **Posts on this page:** 8\ **Page:** 1
**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:** [February 7, 2026, 8:59pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-5-12-supported-ansible-core-versions-when-installing-collections/45292/1 "2026-02-07T20:59:34Z")
# As a user **Supported ansible-core versions when installing collections** # Latest developments None that I know of. This wasn’t discussed at CfgMgmtCamp 2026. # Original text Right now `ansible-galaxy collection install`’s dependency resolver still does not consider `requires_ansible` from `meta/runtime.yml` when installing collections. `requires_ansible` does declare which ansible-core (or ansible-base 2.10 / Ansible 2.9) versions a collection supports. While there is a runtime warning when using a collection with an ansible-core version it does not support, it would prevent a lot of unnecessary issues if `ansible-galaxy collection install` would - like any other good package manager - only install collections for an ansible-core version that are actually supported. This is annoying for a user since when installing a collection on an older ansible-core version, you can easily install a collection that will not work with your ansible-core version. This is also very annoying for collection maintainers and developers since right now, dropping support for an ansible-core version is a **breaking change**. If the package manager (ansible-galaxy) would consider `requires_ansible`, one could start dropping support for ansible-core versions in _minor releases_ according to semantic versioning. ---
**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:** [February 9, 2026, 6:24am UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-5-12-supported-ansible-core-versions-when-installing-collections/45292/2 "2026-02-09T06:24:49Z")
When compiling things yesterday I forgot about something that was mentioned regarding `requires_ansible` during CfgMgmtCamp: since for some reasons many certified collections use `requires_ansible` incorrectly (since ansible-lint for some reason insists that you must only list supported ansible-core versions there) having `ansible-galaxy collection install` considering this could be problematic. (I never understood this ansible-lint rule, I always thought it was wrong to have it enabled by default, and it’s one of the first thing I always disable when using ansible-lint.) ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [February 9, 2026, 9:46am UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-5-12-supported-ansible-core-versions-when-installing-collections/45292/3 "2026-02-09T09:46:53Z")
Reference Ansible Lint rule: [meta-runtime - Ansible Lint Documentation](https://docs.ansible.com/projects/lint/rules/meta-runtime/?h=requires_an) @felixfontein Do you think changing this rule in Ansible Lint to be opt-in via `enable_list` would help with this issue? Obviously it wouldn’t fix the wider issue but it could help other collection maintainers in the future with this? > since for some reasons many certified collections use `requires_ansible` incorrectly What do you mean by this exactly? I’m not quite following. Do you mean by this, they are specifying the most up to date Ansible Core version here instead of the minimum ansible core version their collection supports? And there is confusion around what `requires_ansible` actually means? ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [February 9, 2026, 2:43pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-5-12-supported-ansible-core-versions-when-installing-collections/45292/4 "2026-02-09T14:43:20Z")
fwiw, this is being actively worked on in [ansible-galaxy - only install/download collections which support ansible-core by default by s-hertel · Pull Request #86183 · ansible/ansible · GitHub](https://github.com/ansible/ansible/pull/86183) ---
**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:** [February 9, 2026, 5:51pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-5-12-supported-ansible-core-versions-when-installing-collections/45292/5 "2026-02-09T17:51:14Z")
> [@dbrennand](#): > > Reference Ansible Lint rule: [meta-runtime - Ansible Lint Documentation](https://docs.ansible.com/projects/lint/rules/meta-runtime/?h=requires_an) > > @felixfontein Do you think changing this rule in Ansible Lint to be opt-in via `enable_list` would help with this issue? Obviously it wouldn’t fix the wider issue but it could help other collection maintainers in the future with this? Yes, though I would rather remove it completely. I still don’t see any reason why that rule is there. > [@dbrennand](#): > > > since for some reasons many certified collections use `requires_ansible` incorrectly > > What do you mean by this exactly? I’m not quite following. Do you mean by this, they are specifying the most up to date Ansible Core version here instead of the minimum ansible core version their collection supports? And there is confusion around what `requires_ansible` actually means? I think @nitzmahone mentioned something like that at CfgMgmtCamp, but I don’t remember what exactly he said. The problem seems to be that apparently for some reason, that check [got added to ansible-lint](https://github.com/ansible/ansible-lint/issues/2102) since someone decided that Supported (with capital S) collections must only support Supported ansible-core versions (why that check has to always run eludes me). That was the [only reason I ever heard for that rule](https://github.com/ansible/ansible-lint/issues/3950#issuecomment-1864672907): because it is (or was) required for the RH certification process. For that reason collections seem to unnecessarily restrict their `requires_ansible` string. ---
**Author:** ![oranod](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/oranod/32/1434_2.png) [@oranod](https://forum.ansible.com/u/oranod)\ **Post date:** [March 5, 2026, 7:49pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-5-12-supported-ansible-core-versions-when-installing-collections/45292/6 "2026-03-05T19:49:52Z")
Hey, this has been on my to-do list to catch up with @nitzmahone and clarify what he said. From what I recalled the issue was that certified collections are forced to use the `requires_ansible` key in a way that aligns with the downstream support lifecycle rather than supported `ansible-core` versions. That `requires_ansible` key was originally intended as runtime metadata. It was designed to answer the question “will this collection function on this version of `ansible-core`?” For certified collections this key is being used for unrelated collection metadata, which causes issues for community collections that work on a wider range of core versions because they have to artificially restrict advertising the core versions they actually work on for non-runtime reasons. ---
**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:** [March 5, 2026, 8:35pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-5-12-supported-ansible-core-versions-when-installing-collections/45292/7 "2026-03-05T20:35:15Z")
BTW, [ansible-galaxy - only install/download collections which support ansible-core by default by s-hertel · Pull Request #86183 · ansible/ansible · GitHub](https://github.com/ansible/ansible/pull/86183) just got merged, which implements this. (Its changelog fragment can be improved though, it should more clearly say what this actually means for end-users.) ---
**Author:** ![tima](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/tima/32/854_2.png) [@tima](https://forum.ansible.com/u/tima)\ **Post date:** [March 21, 2026, 10:43pm UTC](https://forum.ansible.com/t/cfgmgmtcamp-2026-discussion-5-12-supported-ansible-core-versions-when-installing-collections/45292/8 "2026-03-21T22:43:25Z")
> [@felixfontein](#): > > The problem seems to be that apparently for some reason, that check [got added to ansible-lint](https://github.com/ansible/ansible-lint/issues/2102) since someone decided that Supported (with capital S) collections must only support Supported ansible-core versions (why that check has to always run eludes me). That was the [only reason I ever heard for that rule](https://github.com/ansible/ansible-lint/issues/3950#issuecomment-1864672907): because it is (or was) required for the RH certification process. Your assessment is spot on about the certification process. Organizations running automation at scale need a predictable operational baseline. They rely on supported collections aligning strictly with supported `ansible-core` versions to manage their risk. The `ansible-lint` rule acts as a guardrail to ensure that alignment stays intact. That said, keeping up with the latest releases is still a solid practice just to benefit from recent bug fixes.