The failure is from bumping semver to include dtolnay/semver@0faefa8, which changes how pre-release tags are handled with requirements. I'll take a closer look tomorrow.

Seems like the dtolnay/semver#54 change makes it no longer possible to use semver version requirements to sort rustc versions while ignoring prerelease tags, that is it appears that 1.4.0-nightly <= 1.5.0 no longer holds.

Which is kinda annoying because that kind of usage was the main motivation for exposing semver in this crate. :)

I wonder if I should add rustc-release-train-specific functions that ignore the prelrease tags, or specify this crate as doing this automatically... (the latter is probably a bad idea though)

it appears that 1.4.0-nightly <= 1.5.0 no longer holds.

I think it's the other way around: 1.4.0 <= 1.5.0-nightly no longer holds. From my reading of the NPM spec, this is to prevent very alpha prereleases being used in place of an earlier stable release. It makes sense in terms of package management, but not here.

I wonder if I should add rustc-release-train-specific functions that ignore the prelrease tags, or specify this crate as doing this automatically... (the latter is probably a bad idea though)

Former makes more sense to me. Arguably, the new behavior is fixing a bug. To get the behavior that makes sense for release trains, we could just use the Ord impl on Version. Eg, this works:

let v1 = Version::parse("1.4.0").unwrap();
let v2 = Version::parse("1.7.0-beta.3").unwrap();

assert!(v1 <= v2);

even though this does not:

let req = VersionReq::parse(">= 1.4.0").unwrap();
let ver = Version::parse("1.7.0-beta.3").unwrap();

assert!(req.matches(&ver));

Ah, interesting. I had assumed that the Ord impl on Version follows the same scheme as version requirments, but if it doesn't then thats a fine replacement, yeah.

Still have to change the example code and maybe deprecate version_matches though, hm...

Still have to change the example code and maybe deprecate version_matches though, hm...

Here are some of approaches:

1. mark it as deprecated, and if version_matches() returns false and there is a prerelease identifier in the version but not the req, panic with a message explaining the replacement of using the Ord impl
2. mark it as deprecated, and emulate existing behavior for Rust prerelease identifiers, panicking if the VersionReq wasn't of a very simple form (minimum version only)
3. mark it as deprecated, and attempt to fully emulate existing behavior
4. remove it entirely, and clearly state in the release notes what the replacement is

I kind of lean towards 4. Changing panics to Result is already a breaking change and people will likely need to revisit things a little. The changes that result are all very minor.

Yeah, will probably just remove it.

I just opened #5 for that change and rebased this PR on top of that one.

@Kimundi ping for your thoughts on on this and #5 :-)