[GH-ISSUE #690] [Question] Precendence between 1.0.0 and 1.0.1-alpha #5584

New Issue

GiteaMirror · 2026-06-15T12:05:36-05:00

GiteaMirror commented

2026-06-15 12:05:36 -05:00

Originally created by @wbzhang2594 on GitHub (Apr 14, 2021).
Original GitHub issue: https://github.com/semver/semver/issues/690

I'm a little obsessive to ask this question. As there isn't an example of it.
In my understanding, "1.0.1-alpha < 1.0.1" and "1.0.0 < 1.0.1".
But is this true of "1.0.0 < 1.0.1-alpha" ?

Originally created by @wbzhang2594 on GitHub (Apr 14, 2021). Original GitHub issue: https://github.com/semver/semver/issues/690 I'm a little obsessive to ask this question. As there isn't an example of it. In my understanding, "1.0.1-alpha < 1.0.1" and "1.0.0 < 1.0.1". But is this true of "1.0.0 < 1.0.1-alpha" ?

GiteaMirror added the question label 2026-06-15 12:05:36 -05:00

GiteaMirror commented

2026-06-15 12:05:37 -05:00

@ljharb commented on GitHub (Apr 14, 2021):

Yes, if you consider prereleases in ranges. https://npmjs.com/node-semver, for example, doesn't include prereleases by default in a number of its range APIs.

@ljharb commented on GitHub (Apr 14, 2021): Yes, if you consider prereleases in ranges. https://npmjs.com/node-semver, for example, doesn't include prereleases by default in a number of its range APIs.

GiteaMirror commented

2026-06-15 12:05:38 -05:00

@wbzhang2594 commented on GitHub (Apr 14, 2021):

Yes, if you consider prereleases in ranges. https://npmjs.com/node-semver, for example, doesn't include prereleases by default in a number of its range APIs.

I just got 404 from the link in your comments. And could provide more detail evidence of the 'yes' answer?
BTW. I got another different result from the tool https://semver.npmjs.com/. When I entered the range "> 0.9.9", the 1.0.0-rc.1 wasn't be selected.

@wbzhang2594 commented on GitHub (Apr 14, 2021): > > > Yes, if you consider prereleases in ranges. https://npmjs.com/node-semver, for example, doesn't include prereleases by default in a number of its range APIs. I just got 404 from the link in your comments. And could provide more detail evidence of the 'yes' answer? BTW. I got another different result from the tool https://semver.npmjs.com/. When I entered the range "> 0.9.9", the 1.0.0-rc.1 wasn't be selected.

GiteaMirror commented

2026-06-15 12:05:39 -05:00

@ljharb commented on GitHub (Apr 14, 2021):

whoops, sorry, https://npmjs.com/semver

By default, prereleases aren't included, so the range wouldn't include the prerelease.

@ljharb commented on GitHub (Apr 14, 2021): whoops, sorry, https://npmjs.com/semver By default, prereleases aren't included, so the range wouldn't include the prerelease.

GiteaMirror commented

2026-06-15 12:05:39 -05:00

@wbzhang2594 commented on GitHub (Apr 15, 2021):

Thanks ljharb. From the page I aware the ">1.0.0" wouldn't include the "1.0.1-alpha". Following description is copied from that page,

If a version has a prerelease tag (for example, 1.2.3-alpha.3) then it will only be allowed to satisfy comparator sets if at least one comparator with the same [major, minor, patch] tuple also has a prerelease tag.
For example, the range >1.2.3-alpha.3 would be allowed to match the version 1.2.3-alpha.7, but it would not be satisfied by 3.4.5-alpha.9, even though 3.4.5-alpha.9 is technically "greater than" 1.2.3-alpha.3 according to the SemVer sort rules. The version range only accepts prerelease tags on the 1.2.3 version. The version 3.4.5 would satisfy the range, because it does not have a prerelease flag, and 3.4.5 is greater than 1.2.3-alpha.7.

@wbzhang2594 commented on GitHub (Apr 15, 2021): Thanks ljharb. From the page I aware the ">1.0.0" wouldn't include the "1.0.1-alpha". Following description is copied from that page, > If a version has a prerelease tag (for example, 1.2.3-alpha.3) then it will only be allowed to satisfy comparator sets if at least one comparator with the same [major, minor, patch] tuple also has a prerelease tag. > For example, **the range >1.2.3-alpha.3 would be allowed to match the version 1.2.3-alpha.7, but it would not be satisfied by 3.4.5-alpha.9**, even though 3.4.5-alpha.9 is technically "greater than" 1.2.3-alpha.3 according to the SemVer sort rules. The version range only accepts prerelease tags on the 1.2.3 version. The version 3.4.5 would satisfy the range, because it does not have a prerelease flag, and 3.4.5 is greater than 1.2.3-alpha.7.

GiteaMirror commented

2026-06-15 12:05:40 -05:00

@alexandrtovmach commented on GitHub (Jun 14, 2021):

@wbzhang2594 is it helpful?

@alexandrtovmach commented on GitHub (Jun 14, 2021): @wbzhang2594 is it helpful?

GiteaMirror commented

2026-06-15 12:05:40 -05:00

@jwdonahue commented on GitHub (Dec 4, 2021):

Apply the rules specified by #11 in the spec:

Major 1 equals Major 1
Minor 0 equals Minor 0
Patch 0 less than Patch 1

You're done, 1.0.0 is less than 1.0.1-anything. But precedence rules only specify the sort order. They do not specify every relevant policy. Given a version history of just:

1.0.0
1.0.1-alpha

Most tools will not automatically update you to 1.0.1-alpha from 1.0.0, unless you specify that you are willing to take prereleases.

Most tools don't actually understand a version range of (1.0.0, 1.5.0-alpha] for instance. Their range notations are ad-hoc and often incomplete. But then, most policies fall into either production or development camps, with different goals in mind. Production has no interest in prereleases and development generally won't allow automatic updates from any version to the next, whether it's prerelease or not. Production wants to take bug fixes automatically, developers want to avoid the unscheduled work that would be involved with automatic updates to prerelease bits. The later is due to the fact that any change in a prerelease version is potentially a breaking change. So they might take automatic updates of release version, but they want only manual updates of prerelease bits.

The SemVer spec is mute on the topic of ranges for good reasons. Handling ranges properly is very hard to get right and requires non-trivial code. The original spec author wanted to avoid limiting adoption due to over-engineering the specification. They simply specified a sort order, without saying anything at all about selection policies. This is a common thread throughout the spec. It leaves many things unstated, while constraining only what must be constrained for the purpose of defining the semantics of the scheme.

@jwdonahue commented on GitHub (Dec 4, 2021): Apply the rules specified by [#11](https://semver.org/#spec-item-11) in the spec: Major 1 equals Major 1 Minor 0 equals Minor 0 Patch 0 less than Patch 1 You're done, 1.0.0 is less than 1.0.1-anything. But precedence rules only specify the sort order. They do not specify every relevant policy. Given a version history of just: 1.0.0 1.0.1-alpha Most tools will not automatically update you to 1.0.1-alpha from 1.0.0, unless you specify that you are willing to take prereleases. Most tools don't actually understand a version range of (1.0.0, 1.5.0-alpha] for instance. Their range notations are ad-hoc and often incomplete. But then, most policies fall into either production or development camps, with different goals in mind. Production has no interest in prereleases and development generally won't allow automatic updates from any version to the next, whether it's prerelease or not. Production wants to take bug fixes automatically, developers want to avoid the unscheduled work that would be involved with automatic updates to prerelease bits. The later is due to the fact that any change in a prerelease version is potentially a breaking change. So they might take automatic updates of release version, but they want only manual updates of prerelease bits. The SemVer spec is mute on the topic of ranges for good reasons. Handling ranges properly is very hard to get right and requires non-trivial code. The original spec author wanted to avoid limiting adoption due to over-engineering the specification. They simply specified a sort order, without saying anything at all about selection policies. This is a common thread throughout the spec. It leaves many things unstated, while constraining only what must be constrained for the purpose of defining the semantics of the scheme.

GiteaMirror commented

2026-06-15 12:05:40 -05:00

@ljharb commented on GitHub (Dec 4, 2021):

#584 will make it unmute on ranges.

@ljharb commented on GitHub (Dec 4, 2021): #584 will make it unmute on ranges.

GiteaMirror commented

2026-06-15 12:05:41 -05:00

@jwdonahue commented on GitHub (Dec 4, 2021):

Yes I know that is in the works. I think it is an interesting exercise. I also believe it doesn't belong in the SemVer spec. Better to establish standard minimal documentation practices that each of the various SemVer conforming tool owners should adhere to, than to establish any range notation scheme, however watered down to fit the common denominators. The SemVer 2.0.0 semantics and syntax are the most common denominator among the available tools.

When a handful of those tools have completely defined their particular scheme in terms of an internationally understood range/interval notation, it wouldn't hurt for them to identify and try to migrate to a common, constantly growing set of range notations. I would hope however, that after the exercise of defining their notations using standard math, they might be motivated to support those standard notations directly in their respective tools.

I think that it should reside in a separate spec. though, independent of SemVer and it's format.

@jwdonahue commented on GitHub (Dec 4, 2021): Yes I know that is in the works. I think it is an interesting exercise. I also believe it doesn't belong in the SemVer spec. Better to establish standard minimal documentation practices that each of the various SemVer conforming tool owners should adhere to, than to establish any range notation scheme, however watered down to fit the common denominators. The SemVer 2.0.0 semantics and syntax are the most common denominator among the available tools. When a handful of those tools have completely defined their particular scheme in terms of an internationally understood range/interval notation, it wouldn't hurt for them to identify and try to migrate to a common, constantly growing set of range notations. I would hope however, that after the exercise of defining their notations using standard math, they might be motivated to support those standard notations directly in their respective tools. I think that it should reside in a separate spec. though, independent of SemVer and it's <version triple><optional prerelease><optional meta> format.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#5584