0.12 should also get newer npm than 2.13.4, shouldn't it?
nodejs/node-v0.x-archive#25915
@zkat @othiym23

@zkat will be downstreaming npm@2.14.3 to nodejs/node tomorrow. As far as the npm team knows, that one change will be cherry-picked elsewhere for other releases. @rvagg or @Fishrock123 should let @zkat know if our understanding is incorrect.

Because of the security patches in npm@2.14.1, it would definitely be nice to get a new npm into Node 0.12.

I think one PR should do and we can do the work on our end to copy it to 0.12, but I guess we'll let you know if we run into trouble!

Rubber stamp LGTM with a new npm.

(Also is changelog-maker not working quite right or?)

@Fishrock123 I went with --simple because this isn't a markdown doc, it's a little bit closer to classic changelog

The release should wait for tonight's libuv release.

I'm running the npm release now. Expect it soon, barring any surprises.

On Fri, Sep 11, 2015 at 5:34 AM Ben Noordhuis notifications@github.com
wrote:

The release should wait for tonight's libuv release.

—
Reply to this email directly or view it on GitHub
#2806 (comment).

kat

There we go: #2822 has the latest npm and you can probably just cherry-pick that over onto 0.12.

the 0.x releases aren't going to happen in a hurry, we have lots of work to do on the build side

Just noting here that 0.12.7 users are still having troubles caused by old npm version.

Comment during the LTS meeting this week was that we probably need to set a timeframe for this so we have a date to work toward for the build infra changes required. This week is a write-off for me and heading in to conference season makes it a bit of a mess, perhaps we should aim for 2-3 weeks for now and see how we go.

Preparing for a release, rebased on to v0.12-staging and included the commits on #3642 (waiting for review).

CI is fine except on Windows @ https://ci.nodejs.org/job/node-test-binary-windows/60/ where we are getting consistent failures of:

not ok 797 - test-dgram-multicast-multi-process.js
#[PARENT] sent 'First message to send' to 224.0.0.114:12346
#[PARENT] sent 'Second message to send' to 224.0.0.114:12346
#[PARENT] sent 'Third message to send' to 224.0.0.114:12346
#[PARENT] sent 'Fourth message to send' to 224.0.0.114:12346
#[PARENT] sendSocket closed
#[CHILD] 4656 received 'First message to send' from {"address":"100.114.8.46","family":"IPv4","port":61410,"size":21}
#[CHILD] 4656 received 'Second message to send' from {"address":"100.114.8.46","family":"IPv4","port":61410,"size":22}
#[CHILD] 4656 received 'Third message to send' from {"address":"100.114.8.46","family":"IPv4","port":61410,"size":21}
#[CHILD] 4656 received 'Fourth message to send' from {"address":"100.114.8.46","family":"IPv4","port":61410,"size":22}
#[PARENT] 4656 received 4 messages total.
#[CHILD] 3128 received 'First message to send' from {"address":"100.114.8.46","family":"IPv4","port":61410,"size":21}
#[CHILD] 3128 received 'Second message to send' from {"address":"100.114.8.46","family":"IPv4","port":61410,"size":22}
#[CHILD] 3128 received 'Third message to send' from {"address":"100.114.8.46","family":"IPv4","port":61410,"size":21}
#[CHILD] 3128 received 'Fourth message to send' from {"address":"100.114.8.46","family":"IPv4","port":61410,"size":22}
#[PARENT] 3128 received 4 messages total.
#[PARENT] Responses were not received within 5000 ms.
#[PARENT] Fail
  ---
  duration_ms: 5.308
  ...
not ok 798 - test-dns.js # TODO : Fix flaky test
#c:\workspace\node-test-binary-windows\RUN_SUBSET\0\VS_VERSION\vs2015\label\win10\test\internet\test-dns.js:371
#    if (err) throw err;
#                   ^
#Error: getaddrinfo ENOTFOUND ipv6.google.com
#    at errnoException (dns.js:44:10)
#    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:94:26)
#test_resolve4
#looking up nodejs.org...
#test_resolve6
#test_reverse_ipv4
#nodejs.org =  [ '104.20.23.46', '104.20.22.46' ]
#test_reverse_ipv6
#test_reverse_bogus
#test_resolveMx
#test_resolveNs
#test_resolveSrv
#test_resolveNaptr
#test_resolveSoa
#test_resolveCname
#test_resolveTxt
#test_lookup_ipv4_explicit
#test_lookup_ipv4_implicit
#test_lookup_ipv4_explicit_object
#test_lookup_ipv4_hint_addrconfig
#test_lookup_ipv6_explicit
#16 tests completed
  ---
  duration_ms: 0.485
  ...
not ok 506 - test-process-config.js
#
#assert.js:86
#  throw new assert.AssertionError({
#        ^
#AssertionError: { target_defaults: 
#   { cflags: [],
#     default_configuration: 'Release',
#     defines: [],
#     include_dirs: [],
#     librar deepEqual { target_defaults: 
#   { cflags: [],
#     default_configuration: 'Release',
#     defines: [],
#     include_dirs: [],
#     librar
#    at Object.<anonymous> (c:\workspace\node-test-binary-windows\RUN_SUBSET\0\VS_VERSION\vs2015\label\win10\test\simple\test-process-config.js:44:8)
#    at Module._compile (module.js:460:26)
#    at Object.Module._extensions..js (module.js:478:10)
#    at Module.load (module.js:355:32)
#    at Function.Module._load (module.js:310:12)
#    at Function.Module.runMain (module.js:501:10)
#    at startup (node.js:129:16)
#    at node.js:814:3
  ---
  duration_ms: 0.156
  ...

I don't know for sure but I reckon that multicast one is flaky for v0.12, it's the process.config one that concerns me. @nodejs/platform-windows I'm going to need some help on this one. node -pe process.config compared with config.gypi on one of the test machines shows the difference to be v8_use_snapshot being false in config.gypi and true in process.config. Is it possible this is an artifact of the fanned build system @joaocgreis? It really should be false in both places.

Release builds are coming out with consistent v8_use_snapshot: false so this seems to be a test config problem .. maybe we need to be providing nosnapshot for vcbuild.bat in the jenkins build config when we are <= 0.12, can you look at that please @joaocgreis?

RC 1 is here: https://nodejs.org/download/rc/v0.12.8-rc.1/

Please help promote this so we can get some testing before going live with 0.12.8.

@rvagg ... just to confirm... I haven't had time to go through the list to check for myself but does this include any of the recent commits in v0.12-staging?

nm! heh... helps if I do a search on the comments before asking.. sigh : #2806 (comment)

Would like to get #3890 included in this if possible.

f0453ca has introduced test/simple/test-domain-with-abort-on-uncaught-exception.js and brought with it #3239.

test-dgram-multicast-multi-process.js was not known to be flaky in the old infra.

@rvagg you are correct about the windows-fanned jobs having broken v0.x for snapshots. In v0.x, vcbuild test-ci sets nosnapshot=1, but node-compile-windows (part of the new fanned jobs) just calls vcbuild.bat release nosign x64

@rvagg it looks like 90393a8 has updated the LICENSE file such that it no longer matches the content of v0.12.8-proposal. In particular the updated LICENSE file references eslint instead of closure_linter and removed the section for wrk.

@rvagg @joaocgreis I believe I fixed the nosnapshot issue in node-compile-windows. A test build is here: https://ci.nodejs.org/job/node-test-commit-windows-fanned/383/

CITGM is passing on 15 different modules

• lodash
• underscore
• request
• commander
• q
• coffee-script
• through2
• moment
• glob
• gulp-util
• jade
• socket.io
• fs-extras
• body-parse
• uglify-js
• rimraf

All failures also fail on v5

• express
  • release fails
  • master passes
• jquery
  • release fails
  • master passes
• yeoman-generator
  • release fails and master fails
• handlebars
  • release fails and master fails

I believe everything is in place for release, I've run builds here: https://ci.nodejs.org/job/iojs+release/303/ but will hold off until tomorrow (my time, somewhere around 10 hours from now) to promote unless something comes up in the meantime to justify a delay. This is what I'm proposing to put up along with the release announcement on the website. I'd appreciate critique from anyone that wants to offer some.

/cc @nodejs/lts @nodejs/website @nodejs/security

v0.12 LTS

This release of v0.12.8 represents the first release of the v0.12 line since it has moved from Stable to LTS (Long-term Support) status. According to the new LTS plan for the Node.js project, v0.12 will continue as LTS until the end of 2015 at which point it will switch to Maintenance and continue as such until the end of 2016 when support will cease.

During LTS, changes included in v0.12.x releases will be limited to bug fixes, security updates, npm updates (limited to npm v2 LTS), documentation updates, and certain performance improvements that can be demonstrated to not break existing applications. After moving to Maintenance mode at the end of 2015, only critical bugs, critical security fixes, and documentation updates will be included.

The Node.js core team will continue to ensure that v0.12 remains a viable platform for production deployment until the end of 2016. However, users of v0.12 should be working on plan to migrate to at least v4 LTS (Argon) as soon as practical.

New build infrastructure

This is the first v0.12 release made with the new build infrastructure operated by the Node.js Foundation. Even though we have done our best to ensure that the build processes and tools are as close as possible to the previous infrastructure, it is possible that some unexpected issues arise from the changes. Please file bug reports on the Node.js GitHub repository if you have trouble upgrading from v0.12.7 to v0.12.8.

Security update

Shortly after this release, we will be announcing two newly discovered security vulnerabilities. One of these vulnerabilities is labelled high severity and impacts all v0.12 releases. We will therefore be releasing a v0.12.9 next week. However, it is strongly recommended that you upgrade to v0.12.8 this week in order to ensure that the changes to the build processes and tools mentioned above do not create problems for your deployments. This way, you will have greater assurance that v0.12.9 builds, which will contain only changes required to fix the security vulnerability, will work as expected in your production environment.

Also, we're going with the original LICENSE.md on v0.12. I had to punt on backporting the changes on master due to some objections to in #3642. That effort is moving to #3979 which is proposing we get proper legal advice before assuming that what we have in v4.x, v5.x and master is actually appropriate. So for now, it still says "Copyright Joyent, Inc. and other Node contributors" etc. in the installers.

@rvagg I'd like to land #3945 but am not sure which branch to land it on. Can this still make it in?

Should we raise awareness about any of these versions on the website by enabling the announcement banner we've got? E.g:

@phillipj this release is not a security update, that'll be next week and it'll be v0.12, v4 and v5 all at once. Today we'll publish a notification of the upcoming patches though.

@trevnorris too late for this release, we've already gone through the smoke testing and even builds, best to wait till next full release. v0.12 is still technically LTS so no reason we can't push it out in a few weeks with that change.

@rvagg Thanks. Didn't care so much until I realized that core is leaking handles via the debugger. So at this point it's technically a bug fix, but nothing serious.

rebuilt @ https://ci.nodejs.org/job/iojs+release/305/

done, files @ http://nodejs.org/download/release/v0.12.8/ announcement @ https://nodejs.org/en/blog/release/v0.12.8/

FYI I did not attach the note at the bottom about the security update in the post, we'll save that news for tomorrow instead