ansible-core 2.19.14 - Maintenance Release and Artifact Checksums

ansible-core 2.19.14 was published on October 5, 2026 as a stable release, not a prerelease. The GitHub release body is short: a pointer to the 2.19 changelog and a list of build artifacts with SHA256 hashes. This post covers what the notes actually give you and how to use it.

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

TL;DR: the notes do not enumerate fixes. They link to the full changelog for the 2.19 branch at the v2.19.14 tag. That file is the source of truth for bug fixes, minor changes, and any security items included in this build.

This post does not list individual fixes, because the release body does not name any. Reading the changelog section for 2.19.14 before you roll it out is the one step that matters. A fourteenth patch in a branch is routine maintenance, and that is all the notes let us say.

If you run Ansible to drive ETL hosts, scraper fleets, or database provisioning, the practical question is the usual one. Does anything in the changelog touch a module, plugin, or behavior your playbooks rely on? Grep the 2.19.14 section for the plugin names you use.

The release lists two artifacts, both with sizes and SHA256 values.

  • Wheel: ansible_core-2.19.14-py3-none-any.whl, 2426850 bytes, SHA256 d518d0e96fa75bedfe9b0a96d5b158aa712d092961824c115140c8677b88ff06.
  • Source distribution: ansible_core-2.19.14.tar.gz, 3432616 bytes, SHA256 1e7612788eaa6b3c87a3670ce86c64b830eba0ae2b3fcb25a772f276704163b4.

The wheel tag py3-none-any means a pure Python build. There is no compiled extension in the wheel, so one artifact serves every platform your control nodes run on. The source distribution is about 1 MB larger than the wheel.

Both files are hosted on PyPI. The release page links to the exact files.pythonhosted.org paths, so you can fetch them without a resolver in the loop.

Hashes in the release notes are useful if your pipeline installs with hash checking. A pinned requirements file entry looks like this:

ansible-core==2.19.14 \
    --hash=sha256:d518d0e96fa75bedfe9b0a96d5b158aa712d092961824c115140c8677b88ff06

Install it with pip install --require-hashes -r requirements.txt. Note that --require-hashes makes pip demand hashes for every dependency in the file, so you need the full transitive set pinned. Tools like pip-compile --generate-hashes produce that.

The tradeoff is plain. Hash pinning stops a swapped or tampered artifact, and it makes upgrades a deliberate commit. The cost is that every patch release needs a requirements bump, and the hashes must be regenerated per platform if you have any dependency that ships platform wheels. For ansible-core itself, the single universal wheel keeps that simple.

If you build container images for execution environments, compare the hash of the downloaded file against the value in the release notes before baking it into a layer. A mismatch should fail the build.

The release notes state no breaking changes and no migration steps. They also state no fixes, so absence of a warning here is not evidence of safety. Treat it as an unknown until you have read the changelog.

A reasonable rollout for a patch release in an existing branch:

  • Read the 2.19.14 section of the changelog.
  • Bump the pin in a branch and run your playbook test suite or a check mode run against staging inventory.
  • Roll to production control nodes after staging passes.

Staying on the 2.19 series means no jump in minor version, so the usual compatibility surface for your collections and Python interpreter on the control node should stay the same. Confirm that against the changelog rather than assuming it.