@othiym23 one small technical problem with this PR is that we've overwritten install.js and build.js in node-gyp in the io.js repo and we'll need to redo that after this merge. Can I suggest either:

• excluding node-gyp from the merge
• applying this phatch which has the benefit of supporting both Node.js and io.js
• or more radically replacing node-gyp with pangyp - my hope is that this package isn't needed because the above PR gets merged but if we can't get that in then my proposal to io.js would be to adopt that repo as an official io.js thing and then come back to the npm client team and lobby to get node-gyp replaced with it.

Onto the topic of npm upgrade process though, I think I'd like to propose the following to the TC about npm (I don't think we've discussed this in a meeting yet?):

• @othiym23 (or whoever is given this responsibility by the npm client team) is given commit access here and given responsibility for maintaining the deps/npm directory with whatever npm version he feels comfortable imposing on us (@latest makes sense but ultimately that call is best left to the npm expert(s))
• we get some kind of changelog with notable changes with each PR (this exists somewhere already doesn't it? can we have copy-pasta into here with upgrades?)
• merging npm updates still follows standard procedure of a PR with some time for comment and possible disagreement by collaborators
• there is enough time between an npm update and a release to allow for testing, probably at least 24 hours in the normal case. I'd also like to see more investment on our end into a beefed up make test-npm (even though it's already much better than we've had till recently) so we can have greater confidence in pushing out brand-new code that's out of our control and likely to be unstudied by most core collaborators.

applying this patch which has the benefit of supporting both Node.js and io.js

I'd much rather @TooTallNate merge your PR and then install the patched version into npm, but if that takes a while, it makes more sense for npm to take that as a floating patch than to have to keep applying it in the io.js repo. If we do decide to do this with a floating patch, the things I pointed out on nodejs/node-gyp#564 apply to the patch for npm as well.

Given that @TooTallNate just landed a patch to node-gyp to handle the changes @iarna made for npm@3, I'd like to give him a little time to speak up before we start talking about forking it.

@othiym23 (or whoever is given this responsibility by the npm client team) is given commit access here

I am happy to act as a point of contact between the io.js and npm CLI teams, but I'm also happy to just submit new npm versions as PRs. Commit access isn't really necessary, especially given the review, test, and feedback cycle you propose (which all sounds sensible to me). If you feel that it's easier to do it this way, I have no objections, but it's not required.

we get some kind of changelog with notable changes with each PR

You already found CHANGELOG.md, but there's also https://github.com/npm/npm/releases, which is notable because there's also https://github.com/npm/npm/releases.atom, if anyone wants to set up notifications for new npm releases (for CI, or whatever).

• merging npm updates still follows standard procedure of a PR with some time for comment and possible disagreement by collaborators
• there is enough time between an npm update and a release to allow for testing, probably at least 24 hours in the normal case.

Absolutely. I'd like to allow io.js and npm to have their own release cadences, without the release of one requiring a scramble to include the latest release of the other. It's rare that it's necessary that the absolutely newest version of npm go out with a new Node or io.js release. It used to be a bigger deal, but the weekly release train and the split between latest and testing have mostly eliminated the problem of bogus npm versions leading to broken Node releases.

I'd also like to see more investment on our end into a beefed up make test-npm (even though it's already much better than we've had till recently) so we can have greater confidence in pushing out brand-new code that's out of our control and likely to be unstudied by most core collaborators.

The npm CLI team has a rewrite of the npm test suite to be more comprehensive and less squirrelly reasonably high on its list of priorities. Reducing test suite run time, being able to meaningfully gauge coverage, and getting all the tests running under node-tap are all things I intend to add to npm's tests. This should make make test-npm both simpler and a better guarantee that new npm releases aren't going to cause problems for io.js releases.

@rvagg I think we can just float our node-gyp patches on top of upgrades for now, like we do with V8. If you agree, I can land this PR and the patches (or maybe @othiym23 can cherry-pick them, if he feels like it.)

By the way, I appreciate that you've started upstreaming our changes!

@othiym23 If I can make a request, would it be possible to include a small changelog in the commit log with just the highlights since the last upgrade? That would make it easier for us to put release notes together. Or should we just copy/paste from CHANGELOG.md?

maybe @othiym23 can cherry-pick them, if he feels like it.

I'll do this. Cherry-picking them onto the PR is actually better than sticking them into npm proper, given that my hope is that eventually npm can just upgrade to a Node / iojs-agnostic version of node-gyp proper.

would it be possible to include a small changelog in the commit log with just the highlights since the last upgrade? That would make it easier for us to put release notes together. Or should we just copy/paste from CHANGELOG.md?

I'm happy to make an even more compressed abstract of the changes for the purposes of io.js, but the contents of CHANGELOG.md / the GitHub releases page are already a curated selection of the changes in the release, omitting things like small typo fixes and test tweaks.

I'll try a 2 or 3-line summary for the next few releases and y'all can decide if that's what you want. npm is going to be going through a lot of minor version bumps for the next month or two as we land the various pieces of CLI support for the new registry features, so this should be a good way to get a feel about where the terseness / completeness know should be turned.

I've cherry-picked those two patches in there, and am happy to squash via rebase – not really sure what the policy is on reapplying previous patches.

We normally keep floating patches separate. LGTM. @rvagg?

lgtm, @bnoordhuis you can land this then this along with V8 4.1 are looking like a 1.0.3

Thanks @othiym23, landed in 9dc8f59...1952219.