Skip to content

Conversation

@zkat
Copy link
Contributor

@zkatzkat commented Sep 18, 2015

Heyo!

This release is the first one to officially include node-gyp (@3.0.1), so it shouldn't need any hotfixes cherry-picked over! Otherwise, I can add a commit to this that bumps it to @3.0.3 (which will come in with next week's downstreaming anyway).

This also includes most of @thefourtheye's graceful-fs upgrades, a Windows fix for npm link, and a removal of our only usage of a deprecated API (process.binding).

You can see the full release notes at https://github.com/npm/npm/releases/tag/v2.14.4

lmk if you want that node-gyp patch added to this PR!

Also note that we finally released npm@3 this week (as you may have heard), but I'll continue to submit npm@2 release PRs -- you can expect a potential slowing, though, since we're also switching to LTS more with npm@2, so it won't see very much in terms of new features and such.

Cheers!

@zkat
Copy link
ContributorAuthor

zkat commented Sep 18, 2015

(oops, I pushed the submit button on this before tests finished running, please hold)

EDIT: We're all good now. :)

@brendanashworthbrendanashworth added the npm Issues and PRs related to the npm client dependency or the npm registry. label Sep 18, 2015
@thefourtheye
Copy link
Contributor

Rubber stamp LGTM

@rvagg
Copy link
Member

@zkat re npm@3, you might want to prime Rebecca on this, but we should be able to start accepting npm@3 pull requests to master and it'll just not get cherry-picked into v4.x but be waiting for a v5 release; we also need to get next-nightly builds out too which can come off master and be usable. npm@2 PRs can just go straight against the v4.x branch from then on.

I'm making an assumption here that there would be no objections amongst @nodejs/collaborators to jumping to npm@3 for v5+ (collaborators: pipe up in here if you think this might not be a good idea).

Also, [email protected] would be good on top of this, unfortunately (sorry), it's got 2 fixes that are fairly important. Thanks!

@Fishrock123
Copy link
Contributor

+1 for npm@3 in master

@zkat
Copy link
ContributorAuthor

zkat commented Sep 19, 2015

Added [email protected] with tests passing locally. Have a good weekend, y'all! Hope there's fun stuff planned. I pinged rebecca about npm@3, too! :)

Fishrock123 pushed a commit that referenced this pull request Sep 20, 2015
PR-URL: #2958 Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Fishrock123 pushed a commit that referenced this pull request Sep 20, 2015
PR-URL: #2958 Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
@Fishrock123
Copy link
Contributor

Thanks, landed in 61d48b4...2c09a53 :)

@zkat
Copy link
ContributorAuthor

zkat commented Sep 20, 2015

Thanks, Jeremiah! :D

Fishrock123 pushed a commit that referenced this pull request Sep 20, 2015
PR-URL: #2958 Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Fishrock123 pushed a commit that referenced this pull request Sep 20, 2015
PR-URL: #2958 Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
@trevnorristrevnorris mentioned this pull request Sep 20, 2015
@rvaggrvagg mentioned this pull request Sep 22, 2015
rvagg added a commit that referenced this pull request Sep 22, 2015
Notable changes * buffer: Fixed a bug introduced in v4.1.0 where allocating a new zero-length buffer can result in the next allocation of a TypedArray in JavaScript not being zero-filled. In certain circumstances this could result in data leakage via reuse of memory space in TypedArrays, breaking the normally safe assumption that TypedArrays should be always zero-filled. (Trevor Norris) #2931. * http: Guard against response-splitting of HTTP trailing headers added via response.addTrailers() by removing new-line ([\r\n]) characters from values. Note that standard header values are already stripped of new-line characters. The expected security impact is low because trailing headers are rarely used. (Ben Noordhuis) #2945. * npm: Upgrade to npm 2.14.4 from 2.14.3, see release notes for full details (Kat Marchán) #2958 - Upgrades graceful-fs on multiple dependencies to no longer rely on monkey-patching fs - Fix npm link for pre-release / RC builds of Node * v8: Update post-mortem metadata to allow post-mortem debugging tools to find and inspect: - JavaScript objects that use dictionary properties (Julien Gilli) #2959 - ScopeInfo and thus closures (Julien Gilli) #2974
rvagg added a commit that referenced this pull request Sep 23, 2015
Notable changes * buffer: Fixed a bug introduced in v4.1.0 where allocating a new zero-length buffer can result in the next allocation of a TypedArray in JavaScript not being zero-filled. In certain circumstances this could result in data leakage via reuse of memory space in TypedArrays, breaking the normally safe assumption that TypedArrays should be always zero-filled. (Trevor Norris) #2931. * http: Guard against response-splitting of HTTP trailing headers added via response.addTrailers() by removing new-line ([\r\n]) characters from values. Note that standard header values are already stripped of new-line characters. The expected security impact is low because trailing headers are rarely used. (Ben Noordhuis) #2945. * npm: Upgrade to npm 2.14.4 from 2.14.3, see release notes for full details (Kat Marchán) #2958 - Upgrades graceful-fs on multiple dependencies to no longer rely on monkey-patching fs - Fix npm link for pre-release / RC builds of Node * v8: Update post-mortem metadata to allow post-mortem debugging tools to find and inspect: - JavaScript objects that use dictionary properties (Julien Gilli) #2959 - ScopeInfo and thus closures (Julien Gilli) #2974 PR-URL: #2995
@iarna
Copy link
Member

@rvagg FYI: Because of npm/npm#9695, I won't be making a pull request to bring in npm@3 till 3.3.5, when that patch is latest.

@rvagg
Copy link
Member

@iarna as per #3000 there's no great rush just yet, we're going to have v4 be LTS soon but you probably have until the next V8 stable before we ship v5 which could be as late as mid-October or later. Will keep you informed of progress though and if we have to punt to v6 then that's fine too because v5 won't end up as LTS anyway.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

npmIssues and PRs related to the npm client dependency or the npm registry.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants

@zkat@thefourtheye@rvagg@Fishrock123@iarna@brendanashworth