^ should not allow prerelease versions

[isaacs]

Expected:

satisfies('1.2.3', '^1.2.2') // true
satisfies('1.2.3-a', '^1.2.2') // false
satisfies('1.2.3-b', '^1.2.3-a') // true
satisfies('1.2.4-a', '^1.2.3-a') // false

^x.y.z-pre should match >= prereleases on x.y.z, but not on any other version.
^x.y.z should not match any prerelease versions, period.

[isaacs]

This is tricky, because the code just replaces caret ranges with >= and < ranges.

Maybe the way to do this is to add another kind of operator that says "don't allow pre-releases within a given range", but that just feels awful and hacky, even for SemVer.

[paulbdavis]

Would it be easier to test for the presence of a - in the version, and only then allow prerelease versions?

Perhaps a fixed suffix (that could apply to all operators?) would signify that prerelease versions are acceptable.

[timoxley]

^ should not allow prerelease versions by default. Same probably even goes for *.

If somebody wants prerelease they should be opting into that chain explicitly. i.e. under what scenarios would you want to automatically go from stable to prerelease?

[tomgco]

@timoxley I agree with you, pre-releases are described under semver point 9 are unstable and should not be automatically updated (Unless an opt-in operator existed, and used).

I am all for a comprehensive fix to match ^x.y.z-pre. However with the inclusion of ^ as the default npm install --save operator, I am starting to see some -pre / -rcN versions creep into our shrink-wraps. Would it be possible to expedite this bug as it could be causing version creep in production applications for many users of 0.10.26?

[isaacs]

@tomgco Well, the default of ~ is the same.

$ semver -r '~1.2.3' '1.2.3-pre' '1.2.4-pre'
1.2.3-pre
1.2.4-pre

Both ~ and ^ should exclude prereleases by default.

[boljen]

What about simply splitting the version and pre-release into two separate ranges? This would be a little more tricky to implement and less efficient but It does give back a lot more flexibility. People wouldn't want alpha-versions in production, but they might want release candidates.

An example could be a range defined like this:

x           // matches only stable versions
x-*         // matches all (pre-)release versions
x-^rc       // matches all (pre-)release versions of at least rc stability
x-beta.*    // matches only pre-release versions with beta stability

[kaelzhang]

We are heavily using prerelease versions and private registry to handle all our test processes. Will it be another major version of semver, i.e. 4.0.0 ?

[isaacs]

Fixed by #99