1.0.0-rc1 >= 1.0

[moll]

Hey,

Is the following behavior intentional?

> SemVer.satisfies("1.0.0-rc1", ">= 1.0.0")
false
> SemVer.satisfies("1.0.0-rc1", ">= 1.0")
true

Happens with SemVer v2.2.1.

[isaacs]

Yes, >= includes prerelease versions. > does not. But I agree with your core issue here, that this is kinda weird.

There is an ongoing discussion about ways to specify a "stableOnly" option. See #62 and #64.

[moll]

Thanks for the reply. Mind elaborating just a sec — so >= on a minor version is meant to include preleases, but if one specifies the patch version as well, then not? I was naívely assuming that 1 and 1.0.0 are equivalent when specifying ranges.

[isaacs]

I see. Yeah, this is a bit weird.

> s.satisfies('1.0.0-beta', '>=1.0.0')
false
> s.satisfies('1.0.0-beta', '>=1.0')
true

[isaacs]

Here's what's going on:

> new s.Range('>=1.0')
<SemVer Range ">=1.0.0-0">
> new s.Range('>=1.0.0')
<SemVer Range ">=1.0.0">

The 1.0 is equivalent to 1.0.0-0 for this purpose. Ie, anything that starts with 1.0, even prereleases. However, because 1.0.0 is a "full" semver, it only means exactly what it says: >=1.0.0, and since 1.0.0-beta is less than 1.0.0 (being a prerelease), it doesn't match.

This is relevant to #62 and #64. Prereleases are really tricky to handle properly in ranges.

[moll]

Thanks.

While we're on the topic of prereleases and you maintaining NPM as well, is the following issue with npm dedupe related to this case?

I've got a shared library with versions 0.1.337 and 1.0.0-rc1.
Library A depends on the shared library with < 1.
Library B depends on the shared library with >= 1.0.0-rc1 < 2.
Running npm dedupe however results in 0.1.337 being jacked up the root folder and thereby breaking library B.

Running npm ls immediately after throws warnings about B requiring >= 1.0.0-rc1 < 2 but will load 0.1.337.

That's with NPM v1.3.25 on Node v0.11.11.

[isaacs]

Fixed consistently in #99.

> s.satisfies('1.0.0-beta', '>=1.0.0')
false
> s.satisfies('1.0.0-beta', '>=1.0')
false

[moll]

👍