Skip to content
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

Closed
wants to merge 3 commits into from
Closed

deps: upgrade npm to 2.6.0 #904

wants to merge 3 commits into from

Conversation

othiym23
Copy link
Contributor

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.

othiym23 and others added 3 commits February 20, 2015 09:03
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>
@othiym23 othiym23 changed the title deps upgrade npm to 2.6.0 deps: upgrade npm to 2.6.0 Feb 20, 2015
@cjihrig
Copy link
Contributor

cjihrig commented Feb 22, 2015

make test-npm passed for me, so LGTM

bnoordhuis pushed a commit that referenced this pull request Feb 22, 2015
PR-URL: #904
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
@bnoordhuis
Copy link
Member

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

@bnoordhuis bnoordhuis closed this Feb 22, 2015
@rvagg
Copy link
Member

rvagg commented Feb 22, 2015

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

@othiym23
Copy link
Contributor Author

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.

@rvagg rvagg mentioned this pull request Feb 23, 2015
@domenic
Copy link
Contributor

domenic commented Feb 24, 2015

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.

@rvagg rvagg added the semver-minor PRs that contain new features and should be released in the next minor version. label Feb 24, 2015
@Fishrock123
Copy link
Contributor

+1 to @domenic

@mikeal
Copy link
Contributor

mikeal commented Feb 24, 2015

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
Copy link
Member

rvagg commented Feb 24, 2015

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
Copy link
Contributor

mikeal commented Feb 24, 2015

@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
Copy link
Member

rvagg commented Feb 24, 2015

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

@rvagg rvagg mentioned this pull request Feb 24, 2015
@mikeal
Copy link
Contributor

mikeal commented Feb 24, 2015

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

@domenic
Copy link
Contributor

domenic commented Feb 24, 2015

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
Copy link
Contributor

mikeal commented Feb 24, 2015

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

@domenic
Copy link
Contributor

domenic commented Feb 24, 2015

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

@rvagg
Copy link
Member

rvagg commented Feb 24, 2015

moved to #942

@rvagg rvagg removed the semver-minor PRs that contain new features and should be released in the next minor version. label Feb 25, 2015
@rvagg
Copy link
Member

rvagg commented Feb 25, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants