v4.2.6 proposal

[MylesBorins]

Notable changes

• Fix regression in debugger and profiler functionality

Known issues

• Some problems with unreferenced timers running during beforeExit are still to be resolved. See #1264.
• Surrogate pair in REPL can freeze terminal. #690
• Calling dns.setServers() while a DNS query is in progress can cause the process to crash on a failed assertion. #894
• url.resolve may transfer the auth portion of the url when resolving between two full hosts, see #1435.

Commits

• [1408f7abb1] - module,src: do not wrap modules with -1 lineOffset (cjihrig) #4298
• [1f8e1472cc] - test: add test for debugging one line files (cjihrig) #4298

[MylesBorins]

/cc @jasnell @rvagg @ofrobots @cjihrig

[MylesBorins]

CI: https://ci.nodejs.org/job/node-test-pull-request/1336/

citgm: https://ci.nodejs.org/job/thealphanerd-smoker/47/

[ofrobots]

LGTM. Thanks for putting this together so fast 🚀!

[rvagg]

@ofrobots would you mind explaining the urgency of this here to justify the quick double-release? We can't afford to hand-wave on something like this.

[MylesBorins]

Seems to be a failure on BSD in CI... re running

https://ci.nodejs.org/job/node-test-commit-freebsd/1011/

edit: BSD CI is green

[ofrobots]

@rvagg Not being able to debug or profile applications is a pretty big regression, in my opinion. You don't want people to deploy with 4.2.5 in production only to realize later, when they suddenly need to, that debugging and profiling do not work. I agree that 4.2.5 is not DOA.

[rvagg]

Not being able to debug or profile applications

That's all I was after, just some justification for this we can point to. I think most of the discussion about this is tucked away in IRC, best to have it explicit on here.

[MylesBorins]

Rerunning citgm (lodash not set to flaky): https://ci.nodejs.org/job/thealphanerd-smoker/48/

Rerunning tests on windows fanned that failed: https://ci.nodejs.org/job/node-test-commit-windows-fanned/1059/

Looked like system related problems in first run

edit: windows passes

[MylesBorins]

CITGM Passes all platforms but ppcle, with an expected failure of eslint and an unexpected failure of watchify

verbose: npm-test:           | not ok 43 should be equal
verbose: npm-test:           | ---                                               
verbose:                     | operator: equal                                   
verbose:                     | expected: 'BEEP BOOP robot\n'                     
verbose:                     | actual:   'BEEP boop robot\n'                     
verbose:                     | at: Socket.<anonymous>                            
verbose:                     | (/tmp/a028dc09-5ee5-487a-ba92-92c38905d20e/watchi���
verbose:                     | fy/test/bin_ignore_watch_default.js:67:9)   

[MylesBorins]

one more CI for posterity: https://ci.nodejs.org/job/node-test-pull-request/1344/

[jasnell]

This LGTM.

Once we get this one spun out (as soon as possible today hopefully) we need to take a look at the process a bit. In order to prevent this from happening again, we need to make sure that everyone is appropriately applying the lts-watch labels when PRs are either opened or landed. There are so many commits that it's difficult to keep track of which ones need to be pulled back and which do not. In the case where a single set of changes and fixes are spread over multiple PRs and commits, it becomes even more important to track. I do see that I was mentioned in the discussion thread for #4298 but I'm a bit backlogged on my github notifications and missed it. Likely the best workflow is to go ahead and mark a PR with lts-watch even if it's not clear that it should land. That will at least put it on the radar when a new LTS release is being prepared. Ideally, the lts-watch would be applied either by the person opening the PR or the person landing the PR if it hasn't already been applied.

Another point ... I think it would be helpful if we had a more robust/formal way of linking to dependent commits included as part of the Commit Metadata. Perhaps adding something like Depends-On: https://github.com/nodejs/node/pull/9999 along side the PR-URL, etc. This would allow those of us backporting commits to more easily and reliably follow the trail of certain commits. I know it can be difficult to know exactly which past commits a new commit is dependent on, but in the case of #4298 it's pretty straightforward.

[MylesBorins]

only failure on CI this round was test-http-exit-delay which there is currently a proposal to remove

#4786

I think it is safe to call that a good CI run... still investigating the citgm failure on ppc.

[MylesBorins]

Rerunning citgm just on ppc for watchify

https://ci.nodejs.org/job/thealphanerd-smoker-ppc/1/

Passes

[MylesBorins]

Started release CI job: https://ci.nodejs.org/job/iojs+release/364/

[brycebaril]

Probably too late due to already being in 4.2.5 as well but 0ae90ec probably should have been a Semver minor (Adds deprecation message)