[GH-ISSUE #106] Incompatibility with git describe --tags #6062

New Issue

GiteaMirror · 2026-06-17T04:29:04-05:00

GiteaMirror commented

2026-06-17 04:29:04 -05:00

Originally created by @isaacs on GitHub (Jun 7, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/106

Create a tag in git called 1.0.0.

Make 5 more commits.

Run git describe --tags. Output will be something like 1.0.0-5-feedcat.

Make 7 more commits, and run it again. Output will be something like 1.0.0-12-deadbeef.

It seems like 1.0.0-12-deadbeef should be > 1.0.0-5-feedcat. However, since only periods separate prerelease identifiers, and any identifier with hyphens is compared alphabetically, this won't be the case.

The fact that the semver 2.0 spec is not compatible with git describe --tags is not so great, in my opinion.

One possible solution would be to split prerelease identifiers by both periods and hyphens.

One bit of oddness that might result is that 1.0.0-asdf-1 would be equal to 1.0.0-asdf.1. But otherwise, it looks like all the existing semantics would be equivalent.

Originally created by @isaacs on GitHub (Jun 7, 2013). Original GitHub issue: https://github.com/semver/semver/issues/106 Create a tag in git called `1.0.0`. Make 5 more commits. Run `git describe --tags`. Output will be something like `1.0.0-5-feedcat`. Make 7 more commits, and run it again. Output will be something like `1.0.0-12-deadbeef`. It seems like `1.0.0-12-deadbeef` should be > `1.0.0-5-feedcat`. However, since only periods separate prerelease identifiers, and any identifier with hyphens is compared alphabetically, this won't be the case. The fact that the semver 2.0 spec is not compatible with `git describe --tags` is not so great, in my opinion. One possible solution would be to split prerelease identifiers by _both_ periods and hyphens. One bit of oddness that might result is that `1.0.0-asdf-1` would be equal to `1.0.0-asdf.1`. But otherwise, it looks like all the existing semantics would be equivalent.

GiteaMirror closed this issue

2026-06-17 04:29:04 -05:00

GiteaMirror commented

2026-06-17 04:29:05 -05:00

@haacked commented on GitHub (Jun 9, 2013):

Thanks for the suggestion, but I don't think we should do this. The git describe --tags isn't outputting a version. It's outputting a tag name separated by a number of commits and an object name. In your example, it just happens to look like a version, but I tend to tag things like v1.0.0-Initial-Release in which case my tag has nothing to do with a SemVer version number.

Also, the current behavior has been this way since 1.0.0 and unless we had an overwhelmingly strong reason to change, I'd prefer not to arbitrarily break every SemVer parser out there by changing this now.

@haacked commented on GitHub (Jun 9, 2013): Thanks for the suggestion, but I don't think we should do this. The `git describe --tags` isn't outputting a version. It's outputting a tag name separated by a number of commits and an object name. In your example, it just happens to look like a version, but I tend to tag things like `v1.0.0-Initial-Release` in which case my tag has nothing to do with a SemVer version number. Also, the current behavior has been this way since 1.0.0 and unless we had an overwhelmingly strong reason to change, I'd prefer not to arbitrarily break every SemVer parser out there by changing this now.

GiteaMirror commented

2026-06-17 04:29:05 -05:00

@isaacs commented on GitHub (Jun 12, 2013):

Fair enough.

@isaacs commented on GitHub (Jun 12, 2013): Fair enough.

GiteaMirror commented

2026-06-17 04:29:06 -05:00

@domenic commented on GitHub (Jun 12, 2013):

+1, it would be great to not have to come up with prerelease names myself and let Git do it.

@domenic commented on GitHub (Jun 12, 2013): +1, it would be great to not have to come up with prerelease names myself and let Git do it.

GiteaMirror commented

2026-06-17 04:29:06 -05:00

@isaacs commented on GitHub (Jun 12, 2013):

@domenic Well, in this case, it'd be post-release names, since they'd come after the SemVer tag.

You can already do git tag v0.10.4-pre though, and then get something like v0.10.4-pre-12-deadbeef out of git. Of course, the fact that this version will be less than v0.10.4-5-feedcat is unfortunate.

@isaacs commented on GitHub (Jun 12, 2013): @domenic Well, in this case, it'd be _post_-release names, since they'd come _after_ the SemVer tag. You can already do `git tag v0.10.4-pre` though, and then get something like `v0.10.4-pre-12-deadbeef` out of git. Of course, the fact that this version will be _less than_ `v0.10.4-5-feedcat` is unfortunate.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6062