[GH-ISSUE #36] question around change of build number strategy #7002

Closed
opened 2026-06-20 16:36:07 -05:00 by GiteaMirror · 3 comments
Owner

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?

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?
Author
Owner

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

<!-- gh-comment-id:8070838 --> @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"
Author
Owner

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

<!-- gh-comment-id:8735496 --> @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?
Author
Owner

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

<!-- gh-comment-id:9081045 --> @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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#7002