Precedence is determined by the first difference when comparing each of
these identifiers from left to right as follows: major, minor, and patch
versions are always compared numerically.
Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1.
Based on which the first difference would be minor in the case of 1.0.0 and 1.1.0-alpha.
So, my question is, should 1.1.0-pre considered to be >= 1.0.0? (Both case makes sense for me but I just want a clarification)
Originally created by @peter-jerry-ye on GitHub (Nov 11, 2025).
Original GitHub issue: https://github.com/semver/semver/issues/1175
Per implementation like semver in Rust and Deno (ported from node I assume), they all think that, `1.1.0-pre` does not satisfies `>= 1.0.0`.
```typescript
import * as semver from "jsr:@std/semver";
const version = semver.parse("1.1.0-pre");
const range = semver.parseRange(">=1.0.0");
console.log(semver.satisfies(version, range)); // false
```
```rust
use semver::{Version, VersionReq};
fn main() {
let req = VersionReq::parse(">=1.0.0").unwrap();
let version = Version::parse("1.1.0-alpha").unwrap();
println!("{}", req.matches(&version)); // false
}
```
Per the spec, however, it only says
> Precedence is determined by the first difference when comparing each of
these identifiers from left to right as follows: major, minor, and patch
versions are always compared numerically.
> Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1.
Based on which the first difference would be minor in the case of `1.0.0` and `1.1.0-alpha`.
So, my question is, should `1.1.0-pre` considered to be `>= 1.0.0`? (Both case makes sense for me but I just want a clarification)
The Rust and Deno interpretations are generally what people do. A pre-release is not a released version, and so doesn't compare with regular versions, the only way you get a pre-release is if you ask for one.
<!-- gh-comment-id:3515207949 -->
@steveklabnik commented on GitHub (Nov 11, 2025):
The Rust and Deno interpretations are generally what people do. A pre-release is not a released version, and so doesn't compare with regular versions, the only way you get a pre-release is if you ask for one.
@peter-jerry-ye commented on GitHub (Nov 11, 2025):
Pre-release versions have a lower precedence than the associated normal version.
I understand that they do compare with regular version, but only defined when comparing with their associated regular version
Or put it in other words. The 'precedence` defined in the spec is not really what we expect when people define 'range' or 'VersionReq'
<!-- gh-comment-id:3515267902 -->
@peter-jerry-ye commented on GitHub (Nov 11, 2025):
> Pre-release versions have a lower precedence than the associated normal version.
I understand that they do compare with regular version, but only defined when comparing with their associated regular version
Or put it in other words. The 'precedence` defined in the spec is not really what we expect when people define 'range' or 'VersionReq'
Semver doesn't currently have ranges, but if it matches #584, prereleases would never be included by default, nor should they be.
<!-- gh-comment-id:3515367121 -->
@ljharb commented on GitHub (Nov 11, 2025):
Semver doesn't currently have ranges, but if it matches #584, prereleases would never be included by default, nor should they be.
@peter-jerry-ye commented on GitHub (Nov 11, 2025):
I see there's a duplicated issue #631 so I'm closing this one.
In reality, I understand that there are cases where we don't want to search for a pre-release version, but the opposite cases exist. I think I would agree with https://github.com/semver/semver/issues/631#issuecomment-1123068190 : the precedence operators should work with precedence. If prereleases were not included, their precedence should not be defined along with the others, which is sadly the case now.
<!-- gh-comment-id:3515540007 -->
@peter-jerry-ye commented on GitHub (Nov 11, 2025):
I see there's a duplicated issue #631 so I'm closing this one.
In reality, I understand that there are cases where we don't want to search for a pre-release version, but the opposite cases exist. I think I would agree with https://github.com/semver/semver/issues/631#issuecomment-1123068190 : the precedence operators should work with precedence. If prereleases were not included, their precedence should not be defined along with the others, which is sadly the case now.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @peter-jerry-ye on GitHub (Nov 11, 2025).
Original GitHub issue: https://github.com/semver/semver/issues/1175
Per implementation like semver in Rust and Deno (ported from node I assume), they all think that,
1.1.0-predoes not satisfies>= 1.0.0.Per the spec, however, it only says
Based on which the first difference would be minor in the case of
1.0.0and1.1.0-alpha.So, my question is, should
1.1.0-preconsidered to be>= 1.0.0? (Both case makes sense for me but I just want a clarification)@steveklabnik commented on GitHub (Nov 11, 2025):
The Rust and Deno interpretations are generally what people do. A pre-release is not a released version, and so doesn't compare with regular versions, the only way you get a pre-release is if you ask for one.
@peter-jerry-ye commented on GitHub (Nov 11, 2025):
I understand that they do compare with regular version, but only defined when comparing with their associated regular version
Or put it in other words. The 'precedence` defined in the spec is not really what we expect when people define 'range' or 'VersionReq'
@ljharb commented on GitHub (Nov 11, 2025):
Semver doesn't currently have ranges, but if it matches #584, prereleases would never be included by default, nor should they be.
@peter-jerry-ye commented on GitHub (Nov 11, 2025):
I see there's a duplicated issue #631 so I'm closing this one.
In reality, I understand that there are cases where we don't want to search for a pre-release version, but the opposite cases exist. I think I would agree with https://github.com/semver/semver/issues/631#issuecomment-1123068190 : the precedence operators should work with precedence. If prereleases were not included, their precedence should not be defined along with the others, which is sadly the case now.