# Ansible's default branch is the one it warns you about

> Ansible is an agentless automation system that drives configuration, deployment and network changes over an existing SSH daemon. The repository is worth reading for the parts that are unusual: a default branch the project itself says carries breaking changes, a requirements file written to be deliberately loose, and one dependency cap tied to a test constant.

**ansible/ansible** — Ansible is a radically simple IT automation platform that makes your applications and systems easier to deploy and maintain. Automate everything from code deployment to network configuration to cloud management, in a language that approaches plain English, using SSH, with no agents to install on remote systems.

- Repository: https://github.com/ansible/ansible
- Website: https://www.ansible.com/
- Stars: 70,811 · Forks: 24,347
- Language: Python
- License: GPL-3.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/ansible-ansible

## devel is the default branch, and the file says it breaks

Clone ansible/ansible and you are on devel, which the branch information describes as the release actively under development, with stable-2.X branches holding the stable releases. The installation section then tells you what that means in practice: a released version can be installed with pip or a package manager, and power users and developers can run the devel branch directly, but although it is reasonably stable, you are more likely to encounter breaking changes there, and the project recommends getting involved in the community if you want to run it.

So the branch you land on by default is the one carrying the warning, and the sentence recommending community involvement is doing quiet work: it is the price of admission for running unreleased code.

The release list shows the shape of a cycle in progress. v2.22.0b2, v2.21.5rc1 and v2.20.10rc1 were all published on 2026-09-29, which means three branches were in prerelease at once and at least two stable-2.X lines are alive. Nothing in that list is a final release, so the tags tell you where the work is, not what to install. The release and maintenance page is the place that answers the second question, and the Bullhorn newsletter is where release announcements and important changes are said to arrive.

## requirements.txt is your install spec, and it is deliberately loose

The comment at the top of requirements.txt explains the policy: the file specifies what dependencies are needed to make the package run rather than for deploying a tested set of packages, so it should be the loosest set possible, only required packages, not optional ones, with the widest range of versions that could be suitable. pyproject.toml then reads the same file, with dependencies pointing at requirements.txt.

Which means the spec your pip install resolves against is the maintainers' development floor, not a tested lock. The entries are jinja2 >= 3.1.0, commented as the point where native macro support was fixed, PyYAML >= 5.1 for Python 3.8 and newer support, cryptography, packaging, and resolvelib. Only one of those has an upper bound.

The consequence is a specific kind of uncertainty. Your install can land on a combination nobody ran, and if a bug appears in templating or YAML parsing the first question is which version of Jinja2 or PyYAML you actually got, not whether your playbook is wrong. Pinning those two in your own environment is the cheap way to make a failure reproducible, and the loose bounds give you the room to do it.

## resolvelib is capped, and the cap is wired to a test constant

One dependency has an upper bound and four comments explaining it. The requirement is resolvelib >= 0.8.0, < 2.0.0, described as the dependency resolver used by ansible-galaxy, and the notes say that 0.x version bumps should be considered major or breaking, that the upper cap should be updated with care at least until 1.0, and that when updating the upper bound you must also update the latest version used in the ansible-galaxy-collection test suite. A link to an upstream issue is included as the reference.

Three consequences, in increasing order of how much they will cost you. Within the allowed range, a resolvelib release can change how ansible-galaxy resolves dependencies, and that is the exact scenario the cap exists for. At the boundary, raising the cap is a two-file change, not a version bump, because the test suite carries its own known-good version. And for anyone vendoring or mirroring the package, the comment block is the only place the reasoning exists, since the constraint itself says nothing about why 2.0.0 is the wall.

It is also the clearest signal in the file about what Ansible considers risky: not the template engine, but the dependency solver.

## Python 3.13 is the floor, and the classifiers name POSIX only

pyproject.toml sets requires-python to >=3.13 and the classifier block lists Python 3.13, 3.14 and 3.15, along with Programming Language :: Python :: 3 :: Only and Operating System :: POSIX. The package name is ansible-core, and the version is read from an attribute in the source rather than written in the manifest, with dependencies read from the file described above.

Two boundaries follow from that block. A host whose system Python is older than 3.13 cannot pip install this at all, which on a long-lived distribution host means a container or a separately managed interpreter before anything else. And the platform list names POSIX with no Windows entry, so a Windows user has no support statement in the package metadata to point at. The repository does not explain the omission, and the development context directory and the module checklists are where a contributor would look.

The build system has a boundary too: setuptools is required at >= 77.0.3 and <= 80.3.1, the lower bound explained as support for license and license-files under PEP 639 and the upper as the latest version tested at release. A newer setuptools in your build environment is outside the tested range.

## Modules in any dynamic language, but the metadata says Python only

One design principle says module development should be allowed in any dynamic language, not just Python. Another says infrastructure should be described in a language that is both machine and human friendly, and that the focus is security and easy auditability, review and rewriting of content. The classifier block says Python 3 only. Those three statements sit in the same project and none of them is wrong, but they describe different layers.

The resolution is that the auditable artefact is the description, not the module. A YAML playbook is what a reviewer reads and what can be rewritten, which is what the principle about review and rewriting is about, and a module in another language is an implementation detail behind it that package metadata has no way to describe. The tension is worth knowing about because it explains why module distribution is a separate concern from the ansible-core install.

For contributors the file points at two places: the development context for ansible-core lives in the context/ directory, and two Developer Guide pages are suggested for review, one on contributing a module and one on conventions, tips and pitfalls. The contributing instructions also ask you to talk to the project before making larger changes, to avoid duplicate effort.

## Changelogs are files in the tree, and backports are cherry-picked

The release process is visible in the root of the repository. A .cherry_picker.toml config and a changelogs/ directory together describe a flow where release notes are files in the tree and fixes move between branches by cherry-pick rather than by re-implementation. That is the mechanism behind the maintenance promise on the stable-2.X branches, and it is also why the Bullhorn newsletter matters: with three branches in prerelease on the same day, the announcement is what tells you which line a change landed in.

The roadmap follows the same shape of small commitments. An initial roadmap is published for a major or minor version, with 2.7 and 2.8 given as the examples, and a roadmap page describes what is planned and how to influence it. Contributions from over 5000 users are credited, the file states the project is substantially coded by humans, and sponsorship from Red Hat is named, which is the background you need when you are deciding whose priorities set that roadmap.

For day to day questions the file routes you to the forum rather than to issue triage on the repository: a help category with tags for ansible, ansible-core and playbook, a chat category, and a news category for project-wide announcements.

## .git-blame-ignore-revs can hide the commit you are looking for

A file named .git-blame-ignore-revs sits at the root. Its presence means the project commits changes that are excluded from git blame, which is the standard way to keep a repository-wide reformat from polluting the history of every line it touched.

The cost is real and it falls on the person doing the audit. When you run blame on a line that a reformatting commit rewrote, you are shown an older commit, and the commit that actually last touched the text is in the ignore list. For a project whose stated design principle is that content should be easy to audit, review and rewrite, that is a place where the convenience of the history and the goal of the history disagree, and the file is where you look to find out which reformatting commits are involved.

The rest of the root follows the same pattern of visible machinery. hacking/ holds developer scripts, bin/ the command entry points, packaging/ and MANIFEST.in the packaging inputs, licenses/ the per-file licence texts that license-files in pyproject.toml refers to, and .mailmap the author mapping for a tree with thousands of contributors. The licence is GNU General Public License v3.0 or later, with COPYING at the root.

## Conclusion

Ansible suits a fleet you already reach over SSH, where the value is in a readable description of the change rather than a binary artefact, and where running as non-root matters. Check three things before adopting it. First, install a released version rather than the devel branch, because the project states that breaking changes are more likely there. Second, read requirements.txt, because the dependency spec is the loosest set the maintainers could justify and your install will resolve versions they have not tested. Third, confirm your hosts run Python 3.13 or newer, since that is the floor in pyproject.toml and the classifiers name POSIX only, with no Windows entry in the block.

## FAQ

### What is Ansible and why is IT used?

Ansible is an IT automation system covering configuration management, application deployment, cloud provisioning, ad-hoc task execution, network automation and multi-node orchestration. It runs over the existing SSH daemon with no agent installed on the remote machine, and describes infrastructure in a language meant to be both machine and human friendly.

### Is Ansible still relevant in 2026?

The last push to the repository was on 2026-09-29, and three prereleases were published that day: v2.22.0b2, v2.21.5rc1 and v2.20.10rc1. The package is marked Development Status :: 5 - Production/Stable in its classifiers.

### Which is better, Ansible or terraform?

The repository makes no comparison with Terraform. Its own stated scope is configuration management, application deployment, cloud provisioning, ad-hoc task execution, network automation and multi-node orchestration, driven over an existing SSH daemon with no custom agents and no additional open ports.

### Is Ansible difficult to learn?

The design principles put an extremely simple setup process and a minimal learning curve first, and ask for a description language that is both machine and human friendly, with security and easy auditability as the focus. The file offers no measurement of how long that takes, so treat the claim as a design target rather than a figure.

### How do I install Ansible?

Install a released version with pip or a package manager, following the linked installation guide; the README gives no command of its own. The published package is ansible-core, which requires Python 3.13 or newer and whose classifiers name POSIX as the operating system.

## Sources

- [Official documentation](https://www.ansible.com/)
- [Official README](https://github.com/ansible/ansible#readme)
- [Project repository](https://github.com/ansible/ansible)
- [Release notes](https://github.com/ansible/ansible/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ansible-ansible