deps: upgrade npm to 2.6.0

[othiym23]

This release of npm includes features to support the new registry and to prepare for npm@3:

• 38c4825 #5068 Add new logout command, and make it do something useful on both bearer-based and basic-based authed clients. (@othiym23)
• c8e08e6 #6565 Warn that peerDependency behavior is changing and add a note to the docs. (@othiym23)
• 7c81a5f #7171 Warn that engineStrict in package.json will be going away in the next major version of npm (coming soon!) (@othiym23)

As always, the floating patches for node-gyp have been applied.

[cjihrig]

make test-npm passed for me, so LGTM

[bnoordhuis]

Thanks Forrest, landed in 1e2fa15...97b4243.

[rvagg]

soooo .. interesting question, is this semver-minor for us? I think my vote is a yes for having npm semver force our semver.

[othiym23]

rvagg: I'm neither opposed or in favor, but I would be interested in hearing a rationale one way or the other. Something to keep in mind, although I'm not sure it should affect the calculus either way, is that there are likely to be lots of semver-minor (and at least one semver-major) bumps of npm over the next few months as we roll out new pieces of the infrastructure for private module support.

[domenic]

I don't think npm semver should drive our semver. It's a bundled dependency with its own rules.

For example when npm@3 is released, no code targeted at the io.js platform will break---it's not a semver-major change.

[Fishrock123]

+1 to @domenic

[mikeal]

There's also the simple fact that your io.js version does not necessarily dictate your npm version because it can be updated independently after installation. This makes it quite different than our other dependencies which cannot be updated independently.

[rvagg]

So we're not considering npm integral to node/io.js now? npm install, npm start, etc. are not how we interact with the platform and changes to that dependency when it is bundled with an io.js release shouldn't impact our semver?

So if we went from 1.9.0 to 1.9.1 but at the same time went from npm 2.7.0 to npm 3.0.0 and broke everyone's npm start that they were using in production deployments that would be OK?

My assumption is that most people using Node (perhaps a little different for the early-adopters using io.js now but that'll change) don't manually upgrade their npm and if they do then they are probably not doing it after every Node upgrade in most cases, therefore, it's a dependency in the same way that V8 is and should dictate our versioning.

[mikeal]

@rvagg The difference is that if someone releases something that requires a new API we add in a minor bump people cannot use that without updating the platform. If the same were to happen when using an npm feature we did not yet support they could update their version of npm. Maybe this distinction doesn't matter though.

[rvagg]

yes, but that doesn't matter -- it's like our openssl dependency which you can (and Linux distributions do) link dynamically so you're using a different version than we bundle

[mikeal]

good poitn about OpenSSL, I've changed my mind, I agree with Rod now :)

[domenic]

I just don't think the npm CLI is a part of io.js's API in the sense of our semver.

Maybe we need to do something more like we do with libuv, v8, etc. That is, every upgrade, we evaluate whether npm has fixed bugs in io.js, or added features to io.js, or broken io.js compatibility with the current major version.

For example I don't think a bundled dependency adding a logout command is a new feature of io.js. If it was exposed by default through require('npm').logout, then sure. But it's not. Similarly npm flattening the dependency tree of installed modules in v3 doesn't break compatibility with io.js 1.x programs. Whereas, perhaps removing npm start would count as a breaking change, or hypothetically adding a npm forever command that they expect people to use to run their io.js programs forever.

[mikeal]

@domenic remember when ~ changed to ^ and new packages broke in older node/npm? The npm API definitely effects the platform and the ecosystem.

[domenic]

Sure, but that's a packaging problem---purely part of npm's API---and not part of the io.js API.

[rvagg]

moved to #942

[rvagg]

removed semver-minor for now pending discussion on #942 so we don't have to defend it on the CHANGELOG until we agree that it's a thing we want to do