Regression in matching prerelease versions

[alexcrichton]

All of the following dependency lines work on stable, but none work on nightly, would be good to know why!

dirs = "*"

openal = "*"

sprs = "0.4.0-alpha.1"

May be related to #2348,

cc @steveklabnik
cc @brson

[steveklabnik]

This is a bugfix change in semver: steveklabnik/semver#54

[steveklabnik]

(I would be willing to cut a certain version if you wanted to keep this bugfix for now to roll out the fix more slowly)

[abonander]

I just discovered this myself as well.

The kicker is that you can still upload crates with prerelease version strings. Is that not being validated the same way?

[steveklabnik]

The issue was that comparisons between prerelease versions were wrong. You can still select them; you just have to explicitly.

On Feb 11, 2016, 19:08 -0500, Austin Bonandernotifications@github.com, wrote:

I just discovered this myself as well.

The kicker is that you can still upload crates with prerelease version strings. Is that not being validated the same way?

—
Reply to this email directly orview it on GitHub(#2381 (comment)).

[alexcrichton]

Ok, it looks like this behavior was added in steveklabnik/semver@0faefa8 (as part of steveklabnik/semver#54 which @steveklabnik mentioned) which was first released in semver 0.2.1. Cargo updated to semver 0.2.1 as part of dd34296 which has not been released yet (but will be part of Cargo 0.9.0).

This does indeed just look like a routine bugfix! I'm going to tag this with docs to ensure we do an audit of the documentation to make sure it reflects reality.

regardless, though, cc @meh (openal author), @tbu (dirs author), and @vbarrielle (sprs author). It looks like these crates will not compile on nightly due to this change, and the fix will be to explicitly depend on the prerelease version of a crate rather than assuming 0.2.0-beta falls into the > 0.2.0 category.

Note that #2222 I believe is still a relevant issue here and if it's actually fixed by upstream semver changes I'd like to check in some tests, otherwise I think it's still a valid issue.

[vbarrielle]

Specifying the prerelease version does work in nightly, but it doesn't work on stable. Indeed, in sprs the issue is because there is a dependency ndarray = "0.4", but ndarray only has alpha versions of 0.4 now. Specifying ndarray = "0.4.0-alpha.3 does fix the problemn in nightly, but in stable there is a cargo error: failed to parse manifest at/home/vincent/Documents/devel/sprs/Cargo.toml``.

I'm not really worried about this though because I'm fine with sprs not building on nightly for an alpha version, and I won't release a non-alpha version while depending on an alpha version of ndarray.

[alexcrichton]

Interesting, thanks for the info @vbarrielle! If it becomes a problem we could roll back the semver changes and have a period where continue the old behavior, but if it's not that serious we can probably let this continue through.

[bluss]

I'm happy that semver did this bug fix actually, I wouldn't want to see a rollback.

[bluss]

I was happy with the ordering changes. But why doesn't "*" match a prerelease version? Seems weird.

[alexcrichton]

cc @steveklabnik, maybe a bug in semver? or maybe intentional?

[steveklabnik]

But why doesn't "*" match a prerelease version? Seems weird.

Because pre-release versions aren't "real" versions. It's sort of implied in the SemVer spec, though it's not particularly clear, but other implementations of Semver, like npm's, only match prerelease versions if you specify prerelease versions:

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.

[bluss]

I have some local tooling that just wants to depend on the latest versions for doc generation and so on. It would be nice to have some kind of version spec that worked for that.

[dwijnand]

What actions are required to resolve this ticket? I'm confused.

[alexcrichton]

Ah this is so old the "regression" is now codified, so closing.