A common release slip: you create the tag v1.16.0 and only then bump the version in the file. The tag points at a commit that still says 1.15.2.

Usually nothing breaks right away. But git checkout v1.16.0 gives you different code, and some package registries record the commit a version was really built from, which is not the one the tag names.

I checked the tags created in 2026 in about 1,200 public repositories: PyPI, crates.io, npm, RubyGems, F-Droid apps, Helm, Flutter, and the most-starred projects on GitHub. One question per tag: does it name the version its own commit declares?

A few real cases, all checkable from public data:

  • smallvec (Rust): tag v1.16.0 points at a commit declaring 1.15.2. crates.io's .cargo_vcs_info.json records that 1.16.0 was published from another commit.
  • pytest-timeout: tag 2.5.0 was cut with 2.4.0 in setup.cfg. The next commit says it "should have been committed before the tag". 2.5.0 was yanked from PyPI.
  • ComfyUI: three tags this year came before the bump; the v0.14.2 release, whose tag declares 0.14.1, ships portable Windows packages.

The most useful finding was about my own check. Most mismatches it reported were false: a monorepo tag for another package (clap_complete-v4.6.1), a pre-release spelled two ways (v2.9.0-rc0 and 2.9.0rc0), build metadata (+45). None of that showed up in my regression corpus, which is pinned to old tags. Measuring outside the lab caught what the lab could not.

One caveat: I lost the sweep's raw output, so I give no rates, only the cases checked by hand.

To avoid it in your project: tag after the commit that bumps the version, or let the release workflow create the tag from the version file.

The check is --tag in closure_drift, a tool I wrote (open source). The full record, with a command to verify each case: https://doi.org/10.5281/zenodo.24054343