A git tag is not a release: requests v2.16.1 declares 2.16.0

Luiz Fernando Nunes da Silva — Sat, 10 Oct 2026 00:05:57 +0000

In psf/requests, the tag v2.16.1 points at code whose __version__.py says 2.16.0. The tag v2.16.0 says the same, and the code differs between them.

Check it in 30 seconds, nothing to install:

curl -sO https://raw.githubusercontent.com/luizfnsilva/closure_drift/v1.1.0/closure_drift.py
git clone -q https://github.com/psf/requests && cd requests
python3 ../closure_drift.py --compare v2.16.0 v2.16.1

DIFFERS UNDER ONE LABEL: both declare 2.16.0, and the code differs
in 2 path(s). If both were published, that label names two things.

Or without the tool, with plain git:

git show v2.16.1:requests/__version__.py | grep __version__
# __version__ = '2.16.0'

The two paths are a fix to how urllib3's version is parsed and a restored module. The tag was cut before the version was bumped. That is common, not a verdict on requests: among the 100 most-downloaded PyPI projects with a public repository, 29 have at least one version label that names two code states.

What a tag does not tell you

A tag is not a release. The tool reads git, so it cannot see which commit a package on PyPI was built from. Two people outside the project showed me where that matters. In ruff, v0.0.268 was tagged and never published. In openai-python, the 0.26.5 on PyPI was built from the commit after the tag.

closure_drift 1.1.0 lets you say which versions were released. Give it a file with one version per line, from your release notes or your registry:

closure-drift --published released.txt

Only tags on the list are compared. A tag left off is left out of the analysis. The tool never calls it unpublished, because it still reads only git.

Then run it in your own repository:

python3 closure_drift.py

One file, no dependencies, read-only. Source and method: https://github.com/luizfnsilva/closure_drift (DOI 10.5281/zenodo.23271569).

Written with AI assistance; every command and number above was run and checked.

29 of the 100 most-downloaded PyPI projects have a version that names two different code states

Luiz Fernando Nunes da Silva — Thu, 08 Oct 2026 15:50:02 +0000

A version number is a string a human edits. When two release tags declare the same version and the code differs, one address now points to two artefacts. Nothing notices, because the version is all anyone recorded.

I wanted to know how often this happens, so I built a small tool to check it and ran it on the 100 most-downloaded PyPI projects with a public repository. The method was fixed before the first run, and no project was tuned.

result	repositories
every version names one code state	59
at least one version names two	29
not enough tags compared	4
no version found, or inconclusive	8

Every collision is listed and can be checked by hand. In requests:

$ closure-drift --compare v2.16.0 v2.16.1
DIFFERS UNDER ONE LABEL: both declare 2.16.0, and the code differs in 2 path(s).

Why it happens

Mostly not carelessness. A tag created before the version was bumped, branch markers such as 7.x, and monorepos where several tag families share one version file. I asked the maintainers of three projects about their cases; all three confirmed what the tool measured.

Checking your own repository

pipx install git+https://github.com/luizfnsilva/closure_drift@v1.0.0
closure-drift            # inside any git repository

It is one file, standard library only, read-only, no network. Exit 0 means clean, 1 means drift, 2 means it could not tell, and the report says why. To stop it before it happens, --would-tag checks a commit before you tag it, and runs as a GitHub Action or a pre-commit hook.

The full study, the method and every collision: https://github.com/luizfnsilva/closure_drift

DEV Community: Luiz Fernando Nunes da Silva

A git tag is not a release: requests v2.16.1 declares 2.16.0

What a tag does not tell you

29 of the 100 most-downloaded PyPI projects have a version that names two different code states

Why it happens

Checking your own repository