# Ansible 5.6.0 has been released **URL:** \ **Category:** Ansible Project\ **Created:** [April 5, 2022, 7:34pm UTC](https://forum.ansible.com/t/ansible-5-6-0-has-been-released/36513 "2022-04-05T19:34:23Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![David\_Moreau\_Simard2](https://avatars.discourse-cdn.com/v4/letter/d/c6cbf5/32.png) [@David\_Moreau\_Simard2](https://forum.ansible.com/u/David_Moreau_Simard2)\ **Post date:** [April 5, 2022, 7:34pm UTC](https://forum.ansible.com/t/ansible-5-6-0-has-been-released/36513/1 "2022-04-05T19:34:23Z")
Hi all, We're happy to announce that the Ansible 5.6.0 package has been released ! Ansible 5.6.0 includes ansible-core 2.12 as well as a curated set of Ansible collections to provide a vast number of modules and plugins. This is a major version update from Ansible 4.x which included ansible-core 2.11 and there may be backwards incompatibilities in the core playbook language. Please see the porting guide (linked at the bottom) for details. How to get it ---
**Author:** ![Nico\_Kadel-Garcia](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/nico_kadel-garcia/32/9998_2.png) [@Nico\_Kadel-Garcia](https://forum.ansible.com/u/Nico_Kadel-Garcia)\ **Post date:** [April 7, 2022, 4:56am UTC](https://forum.ansible.com/t/ansible-5-6-0-has-been-released/36513/2 "2022-04-07T04:56:43Z")
> Hi all, > > We're happy to announce that the Ansible 5.6.0 package has been released ! > > Ansible 5.6.0 includes ansible-core 2.12 as well as a curated set of > Ansible collections to provide a vast number of modules and plugins. I've updated my RPM building tools at [https://github.com/nkadel/ansiblerepo/](https://github.com/nkadel/ansiblerepo/) to version 5.6.0, and sent a few notes to the author of the Fedora rawhide RPM for ansible to include some of my fixes for it. Those include publishing the license files as '%doc' , rather than locked into the package, and segregating the other docs into a separate ansible-doc package. I do believe I sent you a personal note about that when I saw your name on the Fedora packages. > Getting collection updates from Ansible 5 with ansible-core 2.11.x > ----------------------------------------------------------------- > > Ansible 5 includes ansible-core 2.12.x which has raised the minimum > python requirement to python\>=3.8 and users have expressed an interest > in getting collection updates as they ship in Ansible 5 while keeping > ansible-core 2.11.x which still supports python\>=2.7. > An ansible-galaxy requirements file based on the collections from > Ansible 5 has been made available for this use case: > [https://github.com/ansible-community/ansible-build-data/blob/main/5/galaxy-requirements.yaml](https://github.com/ansible-community/ansible-build-data/blob/main/5/galaxy-requirements.yaml) I really wish you or the appropriate upstream maintainer could update the documentation to stop saying this. It's just not true. ansible-core is a dependency it is not included, and it's a very confusing claim. Also, ansible 5 seems to run fine using ansible-core 2.11 releases, with these options for installation::     \* pip3 install --user ansible-core # installs ansible-core with python 3.6     \* pip3 install --user ansible --no-deps # ignores ansible-core version, installs ansible 5.6.0 It's similar to what my RPM .spec files do, though they're more thorough about using RPM dependency management for ansible-core and ansible. They're also more thorough about replacing:        #!/ur/binpython or        #!/usr/bin/env python with:        #!/usr/bin/python3 ---
**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:** [April 7, 2022, 5:40am UTC](https://forum.ansible.com/t/ansible-5-6-0-has-been-released/36513/3 "2022-04-07T05:40:51Z")
Hi Nico, I really wish you would stop repeating this procedure on every Ansible release. If you want things to actually change, start a proper discussion in the appropriate place ([https://github.com/ansible-community/community-topics/](https://github.com/ansible-community/community-topics/)). > \> Getting collection updates from Ansible 5 with ansible-core 2.11.x > \> ----------------------------------------------------------------- > \> > \> Ansible 5 includes ansible-core 2.12.x which has raised the minimum > \> python requirement to python\>=3.8 and users have expressed an > \> interest in getting collection updates as they ship in Ansible 5 > \> while keeping ansible-core 2.11.x which still supports python\>=2.7. > \> An ansible-galaxy requirements file based on the collections from > \> Ansible 5 has been made available for this use case: > \> [https://github.com/ansible-community/ansible-build-data/blob/main/5/galaxy-requirements.yaml](https://github.com/ansible-community/ansible-build-data/blob/main/5/galaxy-requirements.yaml) > > I really wish you or the appropriate upstream maintainer could update > the documentation to stop saying this. It's just not true. You have to distinguish between the PyPi package called `ansible`, and the product/distribution called Ansible. The \*product/distribution\* Ansible consists of both `ansible` and the `ansible-core` PyPi packages. The \*docsite\* ([https://docs.ansible.com/ansible/latest/](https://docs.ansible.com/ansible/latest/)) describes both. The \*changelog\* describes both. The \*porting guide\* also describes both. That is why our announcement is written as it is. We are talking about the product/distribution. The PyPi package `ansible` does indeed depend on `ansible-core` and does not contain it. But that it is split up into two PyPi packages is an \*\*implementation detail\*\* to Ansible users. If they install Ansible by installing the PyPi package `ansible`, they shouldn't (and don't want to) care how exactly the ansible/ansible-playbook/ansible-doc/... binaries and the collections included in Ansible land on their disk. They just want them there to use them, and they want to look at the docsite to find an accurate description on how they work. > Also, ansible 5 seems to run fine using ansible-core 2.11 releases, > with these options for installation:: I don't think anybody claims it does not. But the resulting thing is \*\*not\*\* Ansible of the correct version, but simply a set of collections with the versions as in the PyPi ansible package combined with another ansible-core version. It is \*\*not\*\* what is documented on the docsite, and is \*\*not\*\* what is documented in the changelog and porting guide. For example, it does contain the wrong content for the ansible.builtin collection, and some features that are provided to collections through shared functionality in ansible-core (doc fragments, module utils, plugin base classes) will not be available since you use the wrong version of ansible-core. A very concrete example are new suboptions for the `keyed_groups` option that many inventory plugins offer, for example the community.general.linode inventory plugin: [https://docs.ansible.com/ansible/5/collections/community/general/linode\_inventory.html#parameter-keyed\_groups](https://docs.ansible.com/ansible/5/collections/community/general/linode_inventory.html#parameter-keyed_groups) You only have these new options as documented on the Ansible 5 docsite when you also have ansible-core 2.12 installed. With ansible-core 2.11 you cannot use `default_value` and `trailing_separator`. So if you combine the collections from the `ansible` PyPi version 5 package with ansible-core 2.11, you do get something else than Ansible 5. > It's similar to what my RPM .spec files do, though they're more > thorough about using RPM dependency management for ansible-core and > ansible. They're also more thorough about replacing: If you are replacing shebangs in the Ansible modules contained in the ansible PyPi package: there is zero need to do that. These files are loaded by ansible-core and the shebang is replaced with the correct shebang for the system the module is executed on. It is simply a placeholder. Thanks, Felix Fontein ---
**Author:** ![Michael\_Stroder](https://avatars.discourse-cdn.com/v4/letter/m/7ea924/32.png) [@Michael\_Stroder](https://forum.ansible.com/u/Michael_Stroder)\ **Post date:** [April 7, 2022, 10:14am UTC](https://forum.ansible.com/t/ansible-5-6-0-has-been-released/36513/4 "2022-04-07T10:14:35Z")
> I really wish you would stop repeating this procedure on every Ansible > release. If you want things to actually change, start a proper > discussion in the appropriate place > ([https://github.com/ansible-community/community-topics/](https://github.com/ansible-community/community-topics/)). This topic came up here and is IMHO relevant for normal Ansible users. So please don't try to push it away from the users. > > > Getting collection updates from Ansible 5 with ansible-core 2.11.x > > > ----------------------------------------------------------------- > > > > > > Ansible 5 includes ansible-core 2.12.x which has raised the minimum > > > python requirement to python\>=3.8 and users have expressed an > > > interest in getting collection updates as they ship in Ansible 5 > > > while keeping ansible-core 2.11.x which still supports python\>=2.7. > > > An ansible-galaxy requirements file based on the collections from > > > Ansible 5 has been made available for this use case: > > > [https://github.com/ansible-community/ansible-build-data/blob/main/5/galaxy-requirements.yaml](https://github.com/ansible-community/ansible-build-data/blob/main/5/galaxy-requirements.yaml) > > > > I really wish you or the appropriate upstream maintainer could update > > the documentation to stop saying this. It's just not true. > > You have to distinguish between the PyPi package called `ansible`, and > the product/distribution called Ansible. Understood, but... > The \*product/distribution\* Ansible consists of both `ansible` and the > `ansible-core` PyPi packages. The \*docsite\* > ([https://docs.ansible.com/ansible/latest/](https://docs.ansible.com/ansible/latest/)) describes both. The > \*changelog\* describes both. The \*porting guide\* also describes both. > That is why our announcement is written as it is. We are talking about > the product/distribution. > > The PyPi package `ansible` does indeed depend on `ansible-core` and > does not contain it. But that it is split up into two PyPi packages is > an \*\*implementation detail\*\* to Ansible users. ...I have to agree with Nico that the wording and the versioning also confused me in the beginning. Ansible users like me are interested to know whether they should update or not, especially in the case of security fixes. Doing pip upgrade on PyPI package 'ansible' is easy because it might have a dependency on a newer version of 'ansible-core' which gets pulled in automatically. That's fine. But if there's an important security fix only in ansible-core Ansible users have to be aware to explicitly invoke pip install --upgrade ansible-core to get the updates. So this "implementation detail" is indeed quite relevant to Ansible users who want to properly maintain their controller. Ciao, Michael. ---
**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:** [April 7, 2022, 7:30pm UTC](https://forum.ansible.com/t/ansible-5-6-0-has-been-released/36513/5 "2022-04-07T19:30:53Z")
Hi Michael, > \> I really wish you would stop repeating this procedure on every > \> Ansible release. If you want things to actually change, start a > \> proper discussion in the appropriate place > \> ([https://github.com/ansible-community/community-topics/](https://github.com/ansible-community/community-topics/)). > > This topic came up here and is IMHO relevant for normal Ansible > users. So please don't try to push it away from the users. I'm not saying this cannot / should not be discussed here. I'm mainly saying that 'official' decisions on what happens to the Ansible package are made by discussions and votes in that repository. So discussing that here is on thing, but if you really want to change it (and Nico seems determined), it would be better to (also) start a discussion there. > \> The \*product/distribution\* Ansible consists of both `ansible` and > \> the `ansible-core` PyPi packages. The \*docsite\* > \> ([https://docs.ansible.com/ansible/latest/](https://docs.ansible.com/ansible/latest/)) describes both. The > \> \*changelog\* describes both. The \*porting guide\* also describes both. > \> That is why our announcement is written as it is. We are talking > \> about the product/distribution. > \> > \> The PyPi package `ansible` does indeed depend on `ansible-core` and > \> does not contain it. But that it is split up into two PyPi packages > \> is an \*\*implementation detail\*\* to Ansible users. > > ...I have to agree with Nico that the wording and the versioning also > confused me in the beginning. > > Ansible users like me are interested to know whether they should > update or not, especially in the case of security fixes. > > Doing pip upgrade on PyPI package 'ansible' is easy because it might > have a dependency on a newer version of 'ansible-core' which gets > pulled in automatically. That's fine. > > But if there's an important security fix only in ansible-core Ansible > users have to be aware to explicitly invoke > > pip install --upgrade ansible-core > > to get the updates. So this "implementation detail" is indeed quite > relevant to Ansible users who want to properly maintain their > controller. That's indeed a problem (especially since `pip install --upgrade ansible` will not upgrade dependencies when `ansible` is already at the latest version). One way to (partially) fix this would be to make sure that Ansible is always released at most a day after ansible-core has been released. Right now, the delay can be up to two weeks, which is definitely too long. Also I don't mind to update the release template by adding more information on how ansible-core is 'contained' in ansible. I'm mainly against completely rewriting it with different language which is more technically correct, but less helpful and doesn't work together with the other things (changelog, porting guide, docsite). Cheers, Felix ---
**Author:** ![Michael\_Stroder](https://avatars.discourse-cdn.com/v4/letter/m/7ea924/32.png) [@Michael\_Stroder](https://forum.ansible.com/u/Michael_Stroder)\ **Post date:** [April 7, 2022, 7:44pm UTC](https://forum.ansible.com/t/ansible-5-6-0-has-been-released/36513/6 "2022-04-07T19:44:51Z")
I guess that Ansible users are normally system admins I'd expect to be used to dealing with multiple packages with interdependent version numbers. So technically correct language is probably the most useful form for this audience. Ciao, Michael. ---
**Author:** ![Nico\_Kadel-Garcia](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/nico_kadel-garcia/32/9998_2.png) [@Nico\_Kadel-Garcia](https://forum.ansible.com/u/Nico_Kadel-Garcia)\ **Post date:** [April 7, 2022, 10:46pm UTC](https://forum.ansible.com/t/ansible-5-6-0-has-been-released/36513/7 "2022-04-07T22:46:03Z")
> Hi Michael, > > \> \> I really wish you would stop repeating this procedure on every > \> \> Ansible release. If you want things to actually change, start a > \> \> proper discussion in the appropriate place > \> \> ([https://github.com/ansible-community/community-topics/](https://github.com/ansible-community/community-topics/)). > \> > \> This topic came up here and is IMHO relevant for normal Ansible > \> users. So please don't try to push it away from the users. > > I'm not saying this cannot / should not be discussed here. I'm mainly > saying that 'official' decisions on what happens to the Ansible package > are made by discussions and votes in that repository. So discussing > that here is on thing, but if you really want to change it (and Nico > seems determined), it would be better to (also) start a discussion > there. I've brought it up before at [https://github.com/ansible/ansible/](https://github.com/ansible/ansible/) . Oh, wait! That's not ansible! That's ansible-core! This software split is confusing and means different things to different people. If "ansible" is meant to be both the curated set of ansible collection modules, and ansible-core, bundle ansible collections separately, as the vastly oversized bundle it is, and set "ansible" to pull in that distinctly from ansible-core. The renaming of the "ansible" package to ansible-core and its substitution in the pypi.org package with a tarball which actually installs only ansible\_collection has led to a great deal of confusion, at the expense of admins who need laborious explanations of why every pypi.org bundle for ansible is misnamed and does not match it's installation locaiton. > \> But if there's an important security fix only in ansible-core Ansible > \> users have to be aware to explicitly invoke > \> pip install --upgrade ansible-core > \> > \> to get the updates. So this "implementation detail" is indeed quite > \> relevant to Ansible users who want to properly maintain their > \> controller. > > That's indeed a problem (especially since `pip install --upgrade > ansible` will not upgrade dependencies when `ansible` is already at the > latest version). One way to (partially) fix this would be to make sure > that Ansible is always released at most a day after ansible-core has > been released. Right now, the delay can be up to two weeks, which is > definitely too long. That is a procedural burden, and an unwelcome one. If "ansible" means both, make it explicitly require both as distinct packages. I'd offer patches to bundle it with the distinct name, but I admit that I find the array of uncommon tools used to create this tarball obscure to tune. It's pretty trivial, but ugly, to take the ansible tarball and tweak it into being an ansible\_collections compatible tarball and installable python module instead. > Also I don't mind to update the release template by adding more > information on how ansible-core is 'contained' in ansible. I'm mainly > against completely rewriting it with different language which is more > technically correct, but less helpful and doesn't work together with > the other things (changelog, porting guide, docsite). > > Cheers, > Felix Technical language that lies outright is always confusing and engenders mistrust of its authors. This one, I'm afraid is a fib except in some very strange and underdocumented model where "ansible" is an umbrella term for a suite of software packages, one of which is actually called "ansible" over at pypi.org, and the other of which used to be called "ansible" and is still called "ansible" over at github. It's an unwelcome source of confusion for folks with more productive work to do. Segregating it more carefully will ease the path for people who don't need the very large "ansible\_collections" suite at all, and need only the much smaller and leaner ansible-core. That may not fit the agglomerated suite of software model, but it's a lot smaller and a lot more supportable. Isn't destabilizing agglomeration exactly what triggered the split-off of ansible-core and the ansible\_collections in the first place? It's difficult to be sure because I can't find a transcript or correspondence history of the decision to split these.