mirror of
https://github.com/semver/semver.git
synced 2026-07-11 10:50:26 -05:00
[GH-ISSUE #36] question around change of build number strategy #894
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#894
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 @howarddierking on GitHub (Jun 28, 2012).
Original GitHub issue: https://github.com/semver/semver/issues/36
"Pre-release and build version precedence MUST be determined by comparing each dot separated identifier as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or dashes are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers."
There’s nothing wrong-looking in the Web site examples, but I'm not sure I fully understand this part of the spec. For example, is this true?
1.0.0+1.0.1234.5678 < 1.0.0+build
When you’re comparing apples and oranges like this (e.g. a change of build number strategy), what are the semver rules?
@onlynone commented on GitHub (Aug 27, 2012):
"Numeric identifiers always have lower precedence than non-numeric identifiers."
Therefore the '1' following the plus in the first version has lower precedence than the 'build' in the second. I'm not sure if 'precedence' is the right word to use here, but I think they're just trying to say "all-numeric identifiers compare lower than mixed or all-ASCII identifiers"
@Patio commented on GitHub (Sep 20, 2012):
I don't think builds are a part of the proposed standard. They are just extra information. What I do with builds is give some idea of the time they are created. If you use a 2-dots (so 3-parts) version numbering system like many do nowadays you can give all parts a name e.g. R(elease).V(ersion).U(pdate) [B(uild)] r call either one of the last two P(atch) if you like or use a 3-dot system: r.v.u.p (b) Semantic Version release/version 3 or 2.1 perhaps?
@haacked commented on GitHub (Oct 2, 2012):
Closing this as I believe @onlynone answered the question. Everything after the
+is really up to your discretion how you use it. The spec just describes how these build "identifiers" are compared for precedence.Feel free to open an issue if you have a proposed change.