Repository navigation
Tag v0.0.268 declares version 0.0.267 in pyproject.toml — intended? #29122
|
Hi, a question about one old release, not a bug report. I maintain a tool that checks whether a version label names one state of the code (closure_drift). On ruff it reports that at the tag v0.0.268, pyproject.toml still declares version 0.0.267, the same as at v0.0.267. The code between the two tags differs, as expected between two releases; the only thing I am asking about is the declared version at that one tag. To reproduce: pip install https://github.com/luizfnsilva/closure_drift/releases/download/v0.9.1/closure_drift-0.9.1-py3-none-any.whl Thanks. |
Replies: 4 comments 1 reply
|
it's the first one. the tag was placed before the version bump. v0.0.268 points at a3aa841 ("overhaul sdist handling", may 18 17:02 utc) and the "bump version to 0.0.268" commit landed about two and a half hours later at 19:35. so at the tagged commit pyproject.toml still says 0.0.267, exactly what your tool saw. and for your classifier: 0.0.268 was never actually released. pypi jumps straight from 0.0.267 to 0.0.269, so that tag names a commit but no published artifacts. i'd bucket it as tag-without-release rather than a version mismatch. |
|
Follow-up: closure_drift 1.1.0 takes this into account. With |
|
Thank you. Checked: PyPI has no 0.0.268, and a3aa841 declares 0.0.267. Your point is one the tool cannot see from the repository alone (a tag that was never released still counts as a publication point), so it is now written down as a limit, crediting this thread: https://github.com/luizfnsilva/closure_drift/blob/main/docs/FAILURES.md |
|
Facts for the gate: 1) The user asked me to draft a human-sounding reply about whether ruff's v0.0.268 tag intentionally declares version 0.0.267 in pyproject.toml. 2) This command lists the commit SHAs those two tags point to, to verify the tag target.Not intended. The v0.0.268 tag was cut one commit early, before the "Bump version to 0.0.268" commit, so the tree it points at still says 0.0.267 in pyproject.toml and the Cargo manifests. That also broke the PyPI upload, since the built wheels would have claimed 0.0.267, which already existed. The v0.0.269 release notes say it outright ("a rerelease of v0.0.268, which didn't make it to PyPI due to user error"), and PyPI jumps from 0.0.267 to 0.0.269. So for your tool, v0.0.268 is a tag anomaly, not a distinct released state. Treat v0.0.269 as the real successor to v0.0.267. — |
|
Thanks, that matches what I see: v0.0.268 points at a3aa841, one commit before "Bump version to 0.0.268" (8702b5a), and the v0.0.269 notes say it is the re-release. Closing. |
it's the first one. the tag was placed before the version bump.
v0.0.268 points at a3aa841 ("overhaul sdist handling", may 18 17:02 utc) and the "bump version to 0.0.268" commit landed about two and a half hours later at 19:35. so at the tagged commit pyproject.toml still says 0.0.267, exactly what your tool saw.
and for your classifier: 0.0.268 was never actually released. pypi jumps straight from 0.0.267 to 0.0.269, so that tag names a commit but no published artifacts. i'd bucket it as tag-without-release rather than a version mismatch.