^0.x.y always equivalent to =0.x.y

[isaacs]

See npm/npm#5695

CC @ceejbot @othiym23

[timoxley]

this change needs to be very clearly documented and communicated

Please make this happen in a major npm bump.

edit: looks like this has landed in the npm 2.0 alpha 👍

cc @domenic

[othiym23]

Maybe nerfing of peerDependencies (#5080) should be pulled into 2.0.0 as well, to get all of the pain of this out of the way at once. Either way, yes, this is not a change for npm < 2.0.0.

[isaacs]

Yep, it's in SemVer 3.x, npm 2.x

[voxpelli]

SemVer 3.x mistakenly appears in npm < 2.0.0 currently also though – I opened npm/read-installed#28 regarding that.

npm 1.4's read-installed package will on an update be updated to 2.0.7 which contains SemVer 3.x and thus results in peerDependencies no longer appearing as fulfilled on eg. a npm install.

[isaacs]

@voxpelli Don't run a mass global update. This is why npm bundles its dependencies.

Perhaps npm update should never touch bundledDependencies? Seems like that's a terrible idea anyway.

[timoxley]

Also, if you're going to add special 0.x semantics to ^ it should probably be also added to ~, other than backwards compatibility, is there a rationale behind add special 0.x behaviour to one prefix and not the other? Some people are likely to decide to use ~ not because of patch vs minor, but simply because they want different 0.x semantics. And since we're changing things, maybe the 0.x semantics should be an entirely different symbol altogether.

[othiym23]

@timoxley I wouldn't answer the door soon, because it's probably @rvagg with a claw hammer. 💀

The whole reason ^ was introduced in the first place was because ~'s semantics had gotten hopelessly muddy. I agree that having two sigils that do slightly different things is a recipe for pain, but I'm not in favor of recreating the problems we saw with the move from ~ to ^ all over again by changing the meaning of ~ this late in the game.

[domenic]

+1, ~ is a lost cause. Really glad we were able to fix ^, but no need to mess with ~

[othiym23]

Perhaps npm update should never touch bundledDependencies? Seems like that's a terrible idea anyway.

npm -g update is such a massive footgun in its current form, I'm amazed it's been able to survive this long. I would love to change its semantics to be "update all of the global packages to their latest versions" instead "update all of the dependencies of all of the global packages to their newest versions". I never, ever use npm -g update because it gives me the heebie-jeebies.

That said, yeah, we probably should have bumped read-installed's major version as well. Semver is a cruel and terrible god, but we've dedicated ourselves to it anyway.

[timoxley]

ok, so if ~ lives on as-is, then maybe we make ^ behave the same – without special 0.x semantics – and have some additional operator come into play if people want to opt-in to 0.x handling.

[othiym23]

@timoxley The purpose of this change was to reconcile the behavior of node-semver with the semver.org spec. I get that this change is going to cause yet more confusion for people who are not intimate with the details of the semver spec (read: almost everybody, including me), but I don't think we've fixed the original problem, nor really simplified things, by introducing yet another new sigil into the mix. I think what we've got now is the best call at this point in time.

[isaacs]

Here are the semantics:

~ ==> "Same as ~> in Rubygems"
^ ==> "Allegedly compatible, according to semver.org specification"

It turns out that we were not following the semver.org specification. So that's fixed now. Perhaps npm 2.x's npm init should default to 1.0.0 as the initial version. Perhaps --save should unpack the version range explicitly when writing back to package.json (ie, write as >=1.2.3 <2.0.0-0 rather than ^1.2.3, or 0.2.1 instead of ^0.2.1).

These are both separate issues.