Uh oh!
There was an error while loading. Please reload this page.
child_process: align fork/spawn stdio error msg - #11044
Conversation
sam-github
commented
Jan 27, 2017
@mscdex approved? Do I need to wait 2 days, or can I revert once there are two approvals? |
mscdex
commented
Jan 28, 2017
If nobody else had any questions/suggestions about the original changes, then it would probably be easier to just change the error message here instead of revert + change. |
sam-github
commented
Jan 28, 2017
OK, I'll revise this PR to be an update of the error message. On monday, though. Cheers. |
replaced revert with code, PTAL
sam-github
commented
Jan 30, 2017
@mscdex I fixed the error message, PTAL, sorry I didn't understand what you LGTM was conditional on. |
There was a problem hiding this comment.
I don't know if we want to start adding this kind of information in this way or not. I think it's probably a separate discussion to be had outside of this PR?
There was a problem hiding this comment.
Don't we usually put something in the API docs when we make breaking API changes? I'll check around to see what we've done in the recent past.
There was a problem hiding this comment.
AFAIK we haven't been including version information when it comes to changes in behavior over time. That might be beneficial, but still it's a separate discussion on if we want to start doing that and if so, how something like that would be best conveyed to the end user (presumably not in a free-form way like this note).
There was a problem hiding this comment.
@addaleax (because you did the original YAML markup, I think) @MylesBorins Will this work?
Our 'ADDED' metadata is not granular enough. It tracks API additions, mostly, but it doesn't account for backporting though 00ffa33 gives me the impression it was intended to.
Since it doesn't track changes in APIs, will this note work? Will the FIXME (EDIT: <-- I meant REPLACEME) get processed?
There was a problem hiding this comment.
Will the FIXME (EDIT: <-- I meant
REPLACEME) get processed?
Yup, the releaser will be warned by the build script (which does just a plain “grep”) and replace it.
Our 'ADDED' metadata is not granular enough.
Working on that! ;)
There was a problem hiding this comment.
I think this should instead go inside a default: case in the switch above.
fork()'s support for .stdio strings in 3268863 used a different TypeError string from spawn, unnecessarily.
sam-github
commented
Jan 31, 2017
PTAL @mscdex |
mscdex
commented
Feb 1, 2017
LGTM if CI is ok with it: https://ci.nodejs.org/job/node-test-pull-request/6142/ |
sam-github
commented
Feb 1, 2017
ci: https://ci.nodejs.org/job/node-test-pull-request/6150/ One of the freebsd machines failed a number of cluster tests. Trying again, may be ephemeral. |
jasnell
commented
Feb 2, 2017
The change LGTM but does this need to be semver-major? Are the error conditions changing here? It's not obvious |
jasnell
commented
Feb 2, 2017
Scratch that, the error message change definitely makes this semver-major |
sam-github
commented
Feb 10, 2017
jasnell
commented
Feb 10, 2017
Adding properties to options objects, so long as they are not required, is semver-minor. |
fork()'s support for .stdio strings in 3268863 used a different TypeError string from spawn, unnecessarily. PR-URL: #11044 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net>
jasnell
commented
Feb 11, 2017
Landed in 4cafa60 |
fork()'s support for .stdio strings in 3268863 used a different TypeError string from spawn, unnecessarily. PR-URL: nodejs#11044 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: Brian White <mscdex@mscdex.net>
fork()'s support for .stdio strings in 3268863 used a different
TypeError string from spawn, unnecessarily.