Last checked and updated on 30 May 2026
What Is New in Ansible 4
Ansible 4 is a major release that primarily focuses on updating its core dependencies and removing deprecated functionality to streamline the codebase. It's a foundational update that sets the stage for future improvements rather than introducing a long list of flashy new features.
| Category | Summary |
|---|---|
| Core Updates | Bumped minimum required Python version to 3.8 and Jinja2 to 3.0. Removed support for Python 2.7 and 3.5-3.7. |
| Deprecations Removed | Cleaned up previously deprecated features including the _raw_params workaround, various module utilities, and old-style lookups. |
| Module Improvements | Updates to core modules like apt and apt_repository with new parameters and bug fixes. |
| Bug Fixes | Numerous fixes across the codebase, particularly in module argument handling and the include_vars directive. |
Why did the Python version requirement change?
Ansible 4 now requires Python 3.8 or newer, dropping all support for Python 2.7 and versions 3.5 through 3.7. This change aligns the project with the broader Python ecosystem's support lifecycle, allowing the use of modern language features and libraries.
In practice, this means you'll need to upgrade the Python interpreter on your control node and managed nodes if they're running older versions. The upside is improved performance and access to newer Python features that Ansible's core can now utilize.
What deprecated features were finally removed?
The release removes several long-deprecated features that were cluttering the codebase. The _raw_params workaround for module arguments is completely gone-you'll need to use proper module parameters instead.
Various deprecated module utilities and old-style lookup plugins have also been purged. This cleanup reduces technical debt and makes the codebase more maintainable, though it might break some older playbooks that were still using these deprecated patterns.
How did core modules improve?
Several core modules received meaningful updates. The apt module gained a new dpkg_options parameter for better control over package installation, while apt_repository added support for signed-by option handling.
These incremental improvements address specific pain points that users encountered in daily operations. The changes are practical rather than revolutionary, focusing on making existing functionality more robust and flexible.
What about Jinja2 template changes?
Jinja2 was upgraded to version 3.0, which brings its own set of new features and changes. While this is mostly backward compatible, there might be edge cases where older template syntax behaves differently.
If you have complex templates, it's worth testing them with the new Jinja2 version. The upgrade provides better performance and more expressive template capabilities that you can leverage in your playbooks and templates.
FAQ
Is Ansible 4 a breaking change?
Yes, primarily due to the Python version requirement change and removal of deprecated features. Playbooks that worked on Ansible 2.9 might need adjustments, especially if they used deprecated syntax or run on older Python versions.
Can I upgrade directly from Ansible 2.9 to version 4?
Technically yes, but you should test thoroughly. The jump removes many deprecated features that were still available in 2.9. Check your playbooks for usage of things like _raw_params or old-style lookups first.
What's the most common issue after upgrading?
Python version incompatibility on managed nodes. If your nodes are running Python 3.7 or older, Ansible 4 won't be able to connect to them. You'll need to upgrade Python on those systems first.
Are there any new features I should try first?
Focus on the module improvements like the new dpkg_options in the apt module. The main value isn't in flashy new features but in the modernized foundation that makes future improvements possible.
Should I upgrade my production environment immediately?
Wait until your critical playbooks are tested. While the changes are necessary for the project's health, they might break automation that depended on deprecated behavior. Test in a staging environment first.