You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The earlier tag (v0.3.1rc2) takes precedence. Presumably because it got 'created' in the local checkout more recently, i.e. (simple) tag creation is a local concept. But from some cursory testing, it's how setuptools_scm appears to be getting the most recent tag.
The committerdate ordering, on the other hand, returns the correct ordering:
git tag --sort=-committerdate
v0.3.1
v0.3.1rc2
v0.3.1rc1
v0.3.0rc1
v0.3.0
...
Q: Is this the same for annotated tags?
@SvenRtbg commented on Mar 27, 2017
Tagging with annotated tags not only adds the timestamp and committer account to this tag (and a message that probably nobody cares about), but also allows Git to pick the more recent tag, i.e. the one added later in time, when running git describe.
Solutions
Use a dummy commit to avoid multiple tags.
Don't unshallow for tag creation events.
(?) Use annotated tags.
Propose/implement that setuptools_scm sort tags by committerdate.
Option 2 seems the best here, as the unshallow is unnecessary when the workflow is triggered off tag creation events.
This doesn't work however for the example atop python-versioneer/python-versioneer#79, i.e. 1.0.0 is chosen over 1.0.1 (although surely this would be a case of erroneous tagging and one of these could/should be deleted).
Hm, one other (perhaps more common) way this might happen is if a release candidate gets promoted to the final release without additional changes, so you'd have "v1.0rc1" and "v1.0" tags on the same commit. (This is probably the ideal outcome in any process that involves "release candidates": making no changes between your last candidate and the final release).
Yet in this example, v1.0 would be used, by the very code they committed 4 years prior (above). Maybe I'm missing something. This is the same code kicking around a lot of projects using versioneer, including those who've vendored it. And it seems to work for the case of release candidate not being promoted over release.
The text was updated successfully, but these errors were encountered:
rpanderson
changed the title
Created tag is not used for versioning when multiple tags exist
Latest tag is not used for versioning when multiple tags exist
May 17, 2020
The problem
v0.3.1rc2
and push this tag.v0.3.1
and push.0.3.1rc2
.Example: https://github.com/rpanderson/workflow-sandbox/runs/682565320 (on: create tag v0.3.1).
What's happening here?
setuptools_scm
ran on this shallow checkout, everything would be fine of course (there's only one tag).Same commit, different tag. Reproducing this locally, one can inspect two types of tag ordering native to git,
creatordate
andcommitterdate
.The earlier tag (v0.3.1rc2) takes precedence. Presumably because it got 'created' in the local checkout more recently, i.e. (simple) tag creation is a local concept. But from some cursory testing, it's how setuptools_scm appears to be getting the most recent tag.
The
committerdate
ordering, on the other hand, returns the correct ordering:Q: Is this the same for annotated tags?
Solutions
committerdate
.Option 2 seems the best here, as the unshallow is unnecessary when the workflow is triggered off tag creation events.
The state of actions/checkout
Tagging seems to be a hot topic there, right now!
fetch-depth: 1
and not cloning tags are dangerous defaults actions/checkout#217The solution/conclusions here may change if any of these are resolved.
How does versioneer deal with this scenario?
Since 2011, warner/python-versioneer has dealt with multiple tags. See, e.g. python-versioneer/python-versioneer@0a78af3. This apparently just uses
sorted()
on the refs which seems to suffice, although I have no experience with it on Github Actions.This doesn't work however for the example atop python-versioneer/python-versioneer#79, i.e. 1.0.0 is chosen over 1.0.1 (although surely this would be a case of erroneous tagging and one of these could/should be deleted).
Curiously, @warner points out in a reply to this PR:
Yet in this example, v1.0 would be used, by the very code they committed 4 years prior (above). Maybe I'm missing something. This is the same code kicking around a lot of projects using versioneer, including those who've vendored it. And it seems to work for the case of release candidate not being promoted over release.
The text was updated successfully, but these errors were encountered: