Wildcard VersionReq doesn't match if a Version have pre-release

[onur]

I believe * should match any version and currently it is not matching if a Version have a pre-release. For example:

extern crate semver;

fn main() {
    let wildcard_ver = semver::VersionReq::parse("*").unwrap();
    let another_ver = semver::Version::parse("0.1.0-pre.0").unwrap();

    assert!(wildcard_ver.matches(&another_ver));  // there is no match :(
}

This issue is also affecting cargo. For example symtern only released versions with a pre-release string and using any range syntax in Cargo.toml doesn't work. Including: *, 0.1, ^0.1, 0.1.0 etc.

I tried node's semver and * is matching (satisfying) fine with 0.1.0-pre.0.

> semver.satisfies('0.1.0-pre.0', '*')
true
> semver.satisfies('0.1.0', '*')
true

Ref: onur/docs.rs#80

[steveklabnik]

Yes, this is intended behavior. You only get prerelease versions when explicitly asking for them. This is consistent with other semver implementations, take https://semver.npmjs.com/ and try matching * vs 1.0.0-rc.1.

which then confuses me why you say

I tried node's semver and * is matching (satisfying) fine with 0.1.0-pre.0.

@isaacs, do you know what's up here?

[onur]

Another example from semantic_version python module:

>>> from semantic_version import Spec, Version
>>> Spec('*').match(Version('0.1.0-pre.0'))
True

I think * range is only different in npm. In theory * means any and it should match any valid semver.

[steveklabnik]

I haven't had the time to check, but IIRC Bundler also doesn't give you prerelase explicitly.

In theory * means any and it should match any valid semver.

That depends, it should match any released version, imho, and pre-releases aren't real releases.

Anyway, this library will try to be as compatible with the rest of the ecosystem as possible, but if it's not standard across the ecosystem, then we'll do what I think is right 😉

[isaacs]

Nope, it doesn't, by design.

$ semver -r '*' 1.0.0-pre

$ echo $?
1

https://github.com/npm/node-semver/#prerelease-tags

[isaacs]

Obviously I can't speak for Python's semantic_version module, though. I'm assuming it works for its purposes. Version range specifiers are much less standardized than versions themselves, but cargo and npm are mostly in sync with one another.

[onur]

@isaacs I am wondering why all these examples are returning true:

> var semver = require('semver')
> semver.satisfies('0.1.0-pre.0', '*')
true
> semver.satisfies('0.1.0-pre.0', '0.1')
true
> semver.satisfies('0.1.0-pre.0', '^0')
true
> semver.satisfies('0.1.0-pre.0', '0')
true

I only need this kind of behavior from semver crate. semver crate is returning false for all of these.

[isaacs]

@onur Probably you're using a very outdated version of semver.

> var semver = require('./')
undefined
> semver.satisfies('0.1.0-pre.0', '*')
false
> semver.satisfies('0.1.0-pre.0', '0.1')
false
> semver.satisfies('0.1.0-pre.0', '^0')
false
> semver.satisfies('0.1.0-pre.0', '0')
false
> require('semver/package.json').version
'5.3.0'
> require('./package.json').version
'5.3.0'

[onur]

@isaacs that figures:

> require('semver/package.json').version
'2.1.0'

TBH I don't know why this behavior is changed but old one seems more correct to me. Ranges are useless if a crate have a pre-release string. And * means any except it's not any.

Anyway I am closing this issue since semver crate is using node-semver behavior.