Ansible - what are the differences between version 2, 3, and 4?

Question

Previously I used ansible 2.x and now the latest ansible version is 4.x. Having read Ansible Roadmap and Announcing the Community Ansible 3.0.0 Package but not clear what are the differences among versions 2, 3, and 4. It looks version 2.x (base or core) is included in Ansible 3.x and seemingly in 4.x as well. It is not clear if playbooks developed with Ansible 2.9 is compatible in Ansible 4.x.

How can I clearly understand their differences? Please advise the best resources to understand the differences between Ansible 2, 3, and 4.

• Announcing the Community Ansible 3.0.0 Package

Today, there are 3 distinct artefacts in the Ansible open source world:

Ansible Core - A minimal Ansible language and runtime (soon to be renamed from ansible-base) Ansible Collections on Galaxy (community supported) Ansible community package - Ansible installation including ansible-base/core plus community curated Collections Now that these artefacts are managed separately, their versions are diverging as well. Moving forward, Ansible Core will maintain its existing numbering scheme (similar to the Linux Kernel). The next version of Ansible Core after ansible-base 2.10 will be ansible-core 2.11. The Ansible community package (Ansible Core + community Collections) is adopting semantic versioning. The next version of the Ansible community package after 2.10 is 3.0.0.

Answer 1

Basically, Ansible just wants to separate ansible runtime and modules/plugins/callbacks/actions so they can be managed independently.

On Ansible 3.0 and later, it's now separated into two packages:

• ansible-core (it was ansible-base in ansible 3.0), the runtime and a builtin Collection (a shortlist of core modules/plugins/etc)
• ansible, community curated Collections

The ansible-core package will maintain existing versioning scheme (similar to the Linux Kernel), while ansible package is adopting semantic versioning

So Ansible 4.0 comprises two packages: ansible-core 2.12 (runtime with ansible.builtin Collection) and ansible 4.0 (community curated Collections).

I guess playbook written for ansible 2.9.x will still continue to work and be supported in Ansible 4 (ansible-core 2.12.x). As mentioned by mdaniel, it's also better to start using the qualified module names.

It'll be good to check the release notes for any breaking changes.

More info:

• https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#selecting-an-ansible-artifact-and-version-to-install
• https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html

Answer 2

As very best I can tell, their Q&A blog post lays out the utterly confusing hijacking of the Ansible name and new versioning scheme, and then their "build-data" repo gives the nitty gritty of what underlying ansible-core and associated collections are actually packaged inside each of the new "ansible" releases

It is not clear if playbooks developed with Ansible 2.9 is compatible in Ansible 4.x.

I would suspect that for as long as ansible-core accepts the unqualified module names, the playbooks will continue to work, with the ever present asterisk that the underlying collection could make something required that previously wasn't or even have the run of the mill bugs found in all software

I would also guess that unless your project intends to stay on the legacy ansible versions forever, using the qualified module names are probably the safest futureproofing, although I do dread the horrific verbosity such a change is going to introduce