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.
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.
<!-- gh-comment-id:19170267 -->
@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.
+1, it would be great to not have to come up with prerelease names myself and let Git do it.
<!-- gh-comment-id:19349261 -->
@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 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 thanv0.10.4-5-feedcat is unfortunate.
<!-- gh-comment-id:19350363 -->
@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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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 like1.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-deadbeefshould 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 --tagsis 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-1would be equal to1.0.0-asdf.1. But otherwise, it looks like all the existing semantics would be equivalent.@haacked commented on GitHub (Jun 9, 2013):
Thanks for the suggestion, but I don't think we should do this. The
git describe --tagsisn'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 likev1.0.0-Initial-Releasein 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.
@isaacs commented on GitHub (Jun 12, 2013):
Fair enough.
@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.
@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-prethough, and then get something likev0.10.4-pre-12-deadbeefout of git. Of course, the fact that this version will be less thanv0.10.4-5-feedcatis unfortunate.