-
Notifications
You must be signed in to change notification settings - Fork 28.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deps: upgrade npm to 2.6.0 #904
Conversation
Apply a small patch that makes node-gyp fetch the tarballs from https://iojs.org/ instead of http://nodejs.org/ A patch better suited for inclusion upstream will be put together shortly. PR-URL: nodejs#343 Reviewed-By: Rod Vagg <rod@vagg.org>
* Fetch from the correct url. * Link compiled addons with iojs.lib instead of node.lib. * Disable checksum checks for iojs.lib until our website supports them. PR: nodejs#422 Reviewed-by: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-by: Rod Vagg <rod@vagg.org>
|
PR-URL: #904 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Thanks Forrest, landed in 1e2fa15...97b4243. |
soooo .. interesting question, is this semver-minor for us? I think my vote is a yes for having npm semver force our semver. |
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. |
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. |
+1 to @domenic |
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. |
So we're not considering npm integral to node/io.js now? 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 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. |
@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. |
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 |
good poitn about OpenSSL, I've changed my mind, I agree with Rod now :) |
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 |
@domenic remember when |
Sure, but that's a packaging problem---purely part of npm's API---and not part of the io.js API. |
moved to #942 |
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 |
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 thatpeerDependency
behavior is changing and add a note to the docs. (@othiym23)7c81a5f
#7171 Warn thatengineStrict
inpackage.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.