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

Release proposal: v0.12.8 #2806

Merged
merged 8 commits into from
Nov 25, 2015
Merged

Release proposal: v0.12.8 #2806

merged 8 commits into from
Nov 25, 2015

Conversation

rvagg
Copy link
Member

@rvagg rvagg commented Sep 11, 2015

Same issue re release infrastructure as #2805 but we need to get this working ASAP.

2015.11.25, Version 0.12.8 (LTS)

@brendanashworth brendanashworth added the meta Issues and PRs related to the general management of the project. label Sep 11, 2015
@ChALkeR
Copy link
Member

ChALkeR commented Sep 11, 2015

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

@othiym23
Copy link
Contributor

@zkat will be downstreaming [email protected] 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 [email protected], it would definitely be nice to get a new npm into Node 0.12.

@rvagg
Copy link
Member Author

rvagg commented Sep 11, 2015

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!

@Fishrock123
Copy link
Contributor

Rubber stamp LGTM with a new npm.

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

@rvagg
Copy link
Member Author

rvagg commented Sep 11, 2015

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

@bnoordhuis
Copy link
Member

The release should wait for tonight's libuv release.

@zkat
Copy link
Contributor

zkat commented Sep 11, 2015

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

On Fri, Sep 11, 2015 at 5:34 AM Ben Noordhuis [email protected]
wrote:

The release should wait for tonight's libuv release.


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

kat

@zkat
Copy link
Contributor

zkat commented Sep 11, 2015

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

@rvagg
Copy link
Member Author

rvagg commented Sep 11, 2015

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

@ChALkeR
Copy link
Member

ChALkeR commented Sep 28, 2015

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

@rvagg
Copy link
Member Author

rvagg commented Oct 21, 2015

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.

@ChALkeR ChALkeR added the lts Issues and PRs related to Long Term Support releases. label Oct 28, 2015
bnoordhuis and others added 2 commits November 14, 2015 16:35
Fix the following build error by putting #if guards around the
variables:

    ../src/node.cc: In function 'void node::ParseArgs(int*,
    const char**, int*, const char***, int*, const char***)':
    ../src/node.cc:3037:7: error: 'SSL2_ENABLE' was not declared
    in this scope
           SSL2_ENABLE = true;
           ^
    ../src/node.cc:3039:7: error: 'SSL3_ENABLE' was not declared
    in this scope
           SSL3_ENABLE = true;

Fixes: nodejs/node-v0.x-archive#8645
PR-URL: #3825
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Johan Bergström <[email protected]>
Reviewed-By: James M Snell <[email protected]>
This is a roll-up release that includes all changes to npm since 2.13.4.

PR-URL: #3684
Reviewed-By: Jeremiah Senkpiel <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@rvagg rvagg force-pushed the v0.12.8-proposal branch 3 times, most recently from 8c2e412 to dd77ee5 Compare November 19, 2015 03:56
@rvagg
Copy link
Member Author

rvagg commented Nov 19, 2015

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.

@rvagg
Copy link
Member Author

rvagg commented Nov 19, 2015

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?

@rvagg
Copy link
Member Author

rvagg commented Nov 19, 2015

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.

@jasnell
Copy link
Member

jasnell commented Nov 19, 2015

@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?

@jasnell
Copy link
Member

jasnell commented Nov 19, 2015

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

@jasnell
Copy link
Member

jasnell commented Nov 19, 2015

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

@richardlau
Copy link
Member

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

@orangemocha
Copy link
Contributor

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

@richardlau
Copy link
Member

@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.

@orangemocha
Copy link
Contributor

@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/

@MylesBorins
Copy link
Contributor

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

As part of the fix for logjam, node was upgraded to a
level of openssl which rejects connections to servers that
are using keys smaller than 768 bits. It is still possible,
however, to create a server that uses a smaller key size
and and older client may be able to connect to it.

This PR moves us to a secure by default stance on the
server side as well, preventing the creation of a server
using a dhe key size less than 768. This can be overridden
with the command line option which is also added.

It is derived from

9b35be5

which was landed in later io.js/node versions but makes
the limit 1024.  This PR uses the smaller limit in order
to meet the recomendations for logjam while matching was
was done on the client side in openssl to minimize the
potential impacton users.

The command line option will only be documented in the
release notes and will not be added to the tls
documentation.  The goal is that people who are
upgrading are aware and can use the option if they
run into issues, but otherwise the option is not
visible/used.

PR-URL: #3890
Fixes: nodejs/Release#49
Reviewed-By: Myles Borins <[email protected]>
Reviewed-By: James Snell <[email protected]>
Reviewed-By: Rod Vagg <[email protected]>
Reviewed-By: Shigeki Ohtsu <[email protected]>
@rvagg
Copy link
Member Author

rvagg commented Nov 24, 2015

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.

@rvagg
Copy link
Member Author

rvagg commented Nov 24, 2015

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.

@trevnorris
Copy link
Contributor

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

@phillipj
Copy link
Member

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

skjermbilde 2015-11-24 kl 23 02 38

@rvagg
Copy link
Member Author

rvagg commented Nov 24, 2015

@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.

@trevnorris
Copy link
Contributor

@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.

rvagg and others added 4 commits November 25, 2015 10:04
PR-URL: #3642
Reviewed-By: Johan Bergström <[email protected]>
Reviewed-By: Alexis Campailla <[email protected]>
PR-URL: #3642
Reviewed-By: Johan Bergström <[email protected]>
Reviewed-By: Alexis Campailla <[email protected]>
PR-URL: #3642
Reviewed-By: Johan Bergström <[email protected]>
Reviewed-By: Alexis Campailla <[email protected]>
When MSBuild invokes rc.exe, it passes NODE_TAG unstringified, but
passes it correctly to cl.exe. Hence, this workaround was made to
apply only to the resource file.

Fixes: #2963
PR-URL: #3053
Reviewed-By: Alexis Campailla <[email protected]>
Reviewed-By: Johan Bergström <[email protected]>
@rvagg
Copy link
Member Author

rvagg commented Nov 24, 2015

@rvagg rvagg merged commit 0cdc54a into v0.12 Nov 25, 2015
@rvagg rvagg deleted the v0.12.8-proposal branch November 25, 2015 00:16
@rvagg
Copy link
Member Author

rvagg commented Nov 25, 2015

@rvagg
Copy link
Member Author

rvagg commented Nov 25, 2015

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

rvagg added a commit to rvagg/io.js that referenced this pull request Dec 4, 2015
rvagg added a commit that referenced this pull request Dec 5, 2015
@jasnell jasnell mentioned this pull request Dec 17, 2015
scovetta pushed a commit to scovetta/node that referenced this pull request Apr 2, 2016
jBarz pushed a commit to ibmruntimes/node that referenced this pull request Nov 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lts Issues and PRs related to Long Term Support releases. meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

Successfully merging this pull request may close these issues.