mirror of
https://github.com/semver/semver.git
synced 2026-07-11 05:12:48 -05:00
[GH-ISSUE #136] Explain why build metadata should be ignored when determining version precedence #953
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#953
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dkrikun on GitHub (Jul 8, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/136
This is not an issue really, but a question, why it is recommended to ignore the metadata?
Consider that I have a build server, and I use continuous builds. I want the users of the build (who are developers from the other room) to get the latest version, why then I would like to ignore the build metadata?
EDIT: as a matter of fact, I would use
git describe-like output as a build metadata, so that it contains the exact sha, and also it starts w/ distance from the last tag, which ensures the correct precedence.@Tieske commented on GitHub (Jul 8, 2013):
there have been some lengthy discussions on build data. Check out the closed issues a.o. #109, #95, #92, #77, #70, #61, #60 for a discussion on how it came to be.
In short: if the build changes anything, then it should be a new version. If it doesn't, then it is the same version with the same precedence. Though it carries information, it is not relevant to the version comparison. Or stated otherwise; SemVer does not cover your usecase, but you can support it using your own definition of metadata.
@dkrikun commented on GitHub (Jul 8, 2013):
Looked through the discussions, it seems to be a very sensible decision. It allows me to define my meaning for the metadata, like you said, and indeed I can thus use it to trace source git commits.