ansible-core 2.20.10 - Maintenance Release and Artifact Checksums

ansible-core 2.20.10 was published on October 5, 2026 as a stable release, not a prerelease. The GitHub notes carry no prose summary. They link to the 2.20 changelog and list the two PyPI artifacts with SHA256 digests. For operators, the useful part is verification and pinning.

The full release notes and downloads are on the GitHub release page.

TL;DR: the notes are a pointer plus checksums. There is no inline list of fixes in the release body.

The body of the v2.20.10 release has two parts. The first is a link to changelogs/CHANGELOG-v2.20.rst at the v2.20.10 tag. The second is the artifact list.

That means any claim about individual bug fixes has to come from the changelog file, not from the release page. This post does not list them, because the release body does not. If you run ansible-core in a pipeline that provisions ETL workers or scraper hosts, read the 2.20 changelog section for this tag before you roll it out.

This is the 2.20 line. The patch number is 10, which points to a mature maintenance branch. Patch releases on such a branch are normally narrow in scope. That is an inference from the version number, not something the notes state.

Two artifacts are published to PyPI:

  • Wheel: ansible_core-2.20.10-py3-none-any.whl, 2430672 bytes
  • Source distribution: ansible_core-2.20.10.tar.gz, 3351936 bytes

The wheel is tagged py3-none-any. It is pure Python and not tied to a platform or ABI. One wheel serves every worker image you build, whether it runs on x86 or ARM.

The SHA256 digests from the notes are:

2c7a88ff9bf36a9cfb3bc3838fa6222ea54feedf7f7d94ef9a2ae7591345bfdc  ansible_core-2.20.10-py3-none-any.whl
577b8d3c18e4228310a4e5180c3e133bb3955b378367077bfc643f3c21ebee5c  ansible_core-2.20.10.tar.gz

The tradeoff is simple. Publishing digests on the release page costs nothing and gives you a second channel to compare against PyPI. The cost for you is that someone has to wire the comparison into the build.

If your platform bakes Ansible into container images or runner images, pin both the version and the hash. A requirements file with hash checking does this:

ansible-core==2.20.10 --hash=sha256:2c7a88ff9bf36a9cfb3bc3838fa6222ea54feedf7f7d94ef9a2ae7591345bfdc

Install it with pip install --require-hashes -r requirements.txt. If you use the source distribution instead, swap in the second digest.

Pinning by hash has a winner and a loser. The winner is reproducibility: an image rebuilt in three months gets the same bytes. The loser is the transitive dependency set, since --require-hashes demands hashes for every package in the file. Generate the full set with your lock tool and do not hand edit it.

The release notes do not mention breaking changes or migration steps. That is not proof there are none. Check the changelog for the v2.20.10 tag, and run your playbooks against a staging inventory first. Roll out in stages: one canary runner, then the rest of the fleet. Watch the first scheduled runs for changed module behavior before widening. Keep the previous ansible-core pin in version control so a rollback is a one line revert.