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

The git tag v2.16.1 in the py project requests points to code with a __version__.py file that states 2.16.0. The tag v2.16.0 also points to the same code version. However, the two tags differ in two paths of the code. Despite both tags declaring the same version number, the code differs between them. This discrepancy raises the question of whether the tags should be considered as two different things or if it is just a labeling issue.

A closer examination using git commands reveals that the two paths differ in a fix to how urllib3's version is parsed and a restored module. The tag was created before the version was updated, which is a common occurrence among popular PyPI projects. In fact, 29 out of the 100 most-downloaded PyPI projects with a public repository have at least one version label that points to two different code states.

It's important to note that a git tag does not necessarily indicate a release. The tool used to analyze the tags cannot determine which commit of a package on PyPI was built from. There have been instances where a tag was created but never published, and where the package on PyPI was built from a commit after the tag. Tools like closure_drift 1.1.0 allow users to specify which versions were released by comparing a list of versions provided from release notes or a registry.

Only tags on the list are compared, and any tags left off will not be included in the analysis. The tool is a read-only analysis of git and does not label any tags as unpublished. The source code, method, and findings are available at https://github.com/luizfnsilva/closure_drift (DOI 10.5281/zenodo.23271569).