[GH-ISSUE #1175] Question: how does pre-release compare to the previous version? #6687

New Issue

GiteaMirror · 2026-06-17T05:30:24-05:00

GiteaMirror commented

2026-06-17 05:30:24 -05:00

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.

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

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)

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)

GiteaMirror closed this issue

2026-06-17 05:30:24 -05:00

GiteaMirror commented

2026-06-17 05:30:25 -05:00

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

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

GiteaMirror commented

2026-06-17 05:30:26 -05:00

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

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

GiteaMirror commented

2026-06-17 05:30:26 -05:00

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

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

GiteaMirror commented

2026-06-17 05:30:27 -05:00

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

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

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6687