[GH-ISSUE #136] Explain why build metadata should be ignored when determining version precedence #6077

New Issue

GiteaMirror · 2026-06-17T04:30:44-05:00

GiteaMirror commented

2026-06-17 04:30:44 -05:00

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.

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.

GiteaMirror closed this issue

2026-06-17 04:30:44 -05:00

GiteaMirror commented

2026-06-17 04:30:45 -05:00

@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.

@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.

GiteaMirror commented

2026-06-17 04:30:46 -05:00

@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.

@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.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6077