[GH-ISSUE #5] Segment comparison misses certain scenarios #2719

New Issue

GiteaMirror · 2026-04-25T16:35:09-05:00

GiteaMirror commented

2026-04-25 16:35:09 -05:00

Originally created by @serialseb on GitHub (Dec 12, 2011).
Original GitHub issue: https://github.com/semver/semver/issues/5

Suggesting a clarification that ought to be in the text provided the below is accurate:

From reading the specification, when it comes to build or pre, there is no word on how to compare variable segment numbers.

Specifically, what ought to be the result of 1.0.0+build compared to 1.0.0+build.1 and 1.0.0-pre compared to 1.0.0-pre.beta.

As the specification implies that when build is present it takes precedence over absence of build, and normal takes precendence over pre, I assume the following result:

1.0.0+build.1 < 1.0.0+build
1.0.0-alpha < 1.0.0-alpha.1

The examples however show that 1) is not correct, and should be build < build.1. The text ought to be clarified if that's indeed the desired outcome of builds.

Originally created by @serialseb on GitHub (Dec 12, 2011). Original GitHub issue: https://github.com/semver/semver/issues/5 Suggesting a clarification that ought to be in the text provided the below is accurate: From reading the specification, when it comes to build or pre, there is no word on how to compare variable segment numbers. Specifically, what ought to be the result of `1.0.0+build` compared to `1.0.0+build.1` and `1.0.0-pre` compared to `1.0.0-pre.beta`. As the specification implies that when build is present it takes precedence over absence of build, and normal takes precendence over pre, I assume the following result: ``` 1.0.0+build.1 < 1.0.0+build 1.0.0-alpha < 1.0.0-alpha.1 ``` The examples however show that 1) is not correct, and should be `build < build.1`. The text ought to be clarified if that's indeed the desired outcome of builds.

GiteaMirror closed this issue

2026-04-25 16:35:09 -05:00

GiteaMirror commented

2026-04-25 16:35:10 -05:00

@richardwhiuk commented on GitHub (Dec 26, 2011):

As I understand the following is the case:

1.0.0-pre < 1.0.0-pre.beta < 1.0.0+build < 1.0.0+build.1

In other words, a pre-release version is always less than a none pre-release version (as marked by the dash) and presence is always less than something being there.

The quote currently reads:

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.

This should probably be appended with:

Where there is one identifier with more dot separated sections than an other, then the one with more sections takes precedence.

Or similar words to that effect.

@richardwhiuk commented on GitHub (Dec 26, 2011): As I understand the following is the case: 1.0.0-pre < 1.0.0-pre.beta < 1.0.0+build < 1.0.0+build.1 In other words, a pre-release version is always less than a none pre-release version (as marked by the dash) and presence is always less than something being there. The quote currently reads: ``` 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. ``` This should probably be appended with: ``` Where there is one identifier with more dot separated sections than an other, then the one with more sections takes precedence. ``` Or similar words to that effect.

GiteaMirror commented

2026-04-25 16:35:11 -05:00

@lathanh commented on GitHub (Jan 13, 2012):

Also, it would be helpful for the example to illustrate that a pre-release has higher precedence than a non-pre-release of a lower normal version. This can accomplished with the following insertion (in bold):

1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.0.1-alpha < 1.3.7+build < 1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a.

@lathanh commented on GitHub (Jan 13, 2012): Also, it would be helpful for the example to illustrate that a pre-release has higher precedence than a non-pre-release of a lower normal version. This can accomplished with the following insertion (in bold): > 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < **1.0.1-alpha** < 1.3.7+build < 1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a.

GiteaMirror commented

2026-04-25 16:35:11 -05:00

@GordonSchmidt commented on GitHub (Dec 6, 2012):

I have a totally different comparison problem.
The specification says, in pre-releases and builds numeric values are lower than string values - but there is no definition, what should be interpreted as numeric value. Maybe there already is a specification somewhere - then it should be linked. For example are the last parts of these versions numeric or strings: 1.2.3-e0f985a, 1.2.3+45.6-7, 1.2.3-0x1f?

@GordonSchmidt commented on GitHub (Dec 6, 2012): I have a totally different comparison problem. The specification says, in pre-releases and builds numeric values are lower than string values - but there is no definition, what should be interpreted as numeric value. Maybe there already is a specification somewhere - then it should be linked. For example are the last parts of these versions numeric or strings: 1.2.3-e0f985a, 1.2.3+45.6-7, 1.2.3-0x1f?

GiteaMirror commented

2026-04-25 16:35:12 -05:00

@haacked commented on GitHub (Dec 6, 2012):

Numeric values refer to the colloquial definition of a base 10 numbering system (aka 0-9). It's not referring to any other base systems.

@haacked commented on GitHub (Dec 6, 2012): Numeric values refer to the colloquial definition of a base 10 numbering system (aka `0-9`). It's not referring to any other base systems.

GiteaMirror commented

2026-04-25 16:35:12 -05:00

@haacked commented on GitHub (Dec 20, 2012):

@serialseb or @richardwhiuk, mind submitting a PR that closes this issue and contains your suggested text? You can do it through the web UI by editing the semver.md file. It'll automatically fork the repo and create a pull request.

@haacked commented on GitHub (Dec 20, 2012): @serialseb or @richardwhiuk, mind submitting a PR that closes this issue and contains your suggested text? You can do it through the web UI by editing the `semver.md` file. It'll automatically fork the repo and create a pull request.

GiteaMirror commented

2026-04-25 16:35:13 -05:00

@haacked commented on GitHub (Mar 13, 2013):

We're planning to change the meaning of build metadata to be purely metadata which does not affect the version.

Thus:

1.0.0+build.1 = 1.0.0+build as far as the public API is concerned. No precedence can be determined.
1.0.0-alpha < 1.0.0-alpha.1 correct me if I'm wrong, but I believe this case is already clear in the spec.

@haacked commented on GitHub (Mar 13, 2013): We're planning to change the meaning of build metadata to be purely metadata which does not affect the version. Thus: - `1.0.0+build.1` = `1.0.0+build` as far as the public API is concerned. No precedence can be determined. - `1.0.0-alpha` < `1.0.0-alpha.1` correct me if I'm wrong, but I believe this case is already clear in the spec.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2719