uv: let's discuss the backport policy for LTS

Right now Node 4.x is running libuv 1.8.0. Since libuv follows semver, any further versions in the v1.x branch have a backwards compatible API and a stable ABI.

There won't be another libuv 1.8.X, because we are in the v1.9.x cycle now, so Node v4.x should adopt the latest and greatest, as a general rule.

Now, given the current stdio situation (#6456) let's wait for that to settle before taking action, but I wanted to get the ball rolling.

Edit: The Plan

I'm +1 on backporting given:

enough delay to let it prove in Node Current
review by LTS team of the changes being introduced and explicit sign-off by them

cc @nodejs/lts

@saghul

This works for me in general but... my chief concern would be subtle behavior changes such as the stdio small block / flushing issue . Given the impact that has had on the ecosystem I would rather hold off until those issues are adequately resolved. (As suggested by @saghul ;)...)

@rvagg

I think it should come down to a risk/reward analysis which would be what I think the conditions @rvagg lists are meant to address. If there is a benefit to the LTS release in terms of fixing defects/problems and the level of change is acceptable, then I believe we should pull it in. If instead it is only new features and there is significant change then maybe its better to wait as LTS users likely value stability over "new". The balance might also depend on how far into the LTS cycle a release is. For example I don't think pulling in the latest into an LTS release a month or two before it goes out of service would make sense.

@mhdawson

@mhdawson it's not only the new features, it's the bugfixes that matter here. LTS won't get any Node code backported which uses the new APIs, so that's fine. As it stands, Node 4 is running an unmaintained version of libuv, not even security bugs will make a v1.8.x happen.

@jasnell bugs do and will happen. the stdio thing was by no means an intended behavior change, it's still under investigation.

@saghul

@saghul ... yep, understood. The point is only that for the LTS stream we need to be much more conservative about how "up to date" we want to be. Letting things sit in current for a while to ensure that there are no significant regressions makes the most sense here.

@saghul

I'm not entirely opposed to the update but like others I am concerned about the various subtle changes introduced in 1.9.x

@saghul we should likely use this issue to keep track of the problems / solutions. Would you be willing to do so in the top comment?

I'm only aware of a single problem. Which I'm willing to help resolve (see #6456 (comment)).

Now, this is an interesting dilemma. From libuv's perspective, we fixed a bug, and tty writes are as non-blocking as they were, but Node was relying on "undefined behavior".

Let's try to get this solved together. Here is a tentative patch: libuv/libuv#878

Since Debian is currently wondering about the status of this, I'll make a status update. Note that as far as I'm concerned, there is only one problem caused fater the 1.9.X upgrade.

in libuv 1.9.0 we switched from reopening /dev/tty to reopening ttynemae(3) in uv_tty_init: Reopen ttyname() instead of /dev/tty libuv/libuv#779
turns out, that while kqueue can't work with a fd referring to /dev/tty it can work with one pointing to whatever ttyname(3) returns
this means that after 1.9.0, the OSX select trick is no longer used for stdio ttys
as luck would have had it, there was a bug in the OSX select trick handling code: darwin: fix setting fd to non-blocking in select(() trick libuv/libuv#879 which made tty handles blocking on OSX when the fallback was used (always)
there is a dependency on this behavior by many CLI apps
shit hit the fan

The inadvertent change in behavior only affects OSX, and once #6895 lands, thus restoring the old behavior in OSX we should be able to backport the libuv upgrade plus that workaround to LTS.

#6895 has landed, I'll wait until it makes it to a v6 release and then back port the libuv upgrade + that patch to v4. Is everyone OK with this?

yes, but I'd still like to be very conservative on timing for this, it's possible other things might arise in v6

but yes, a PR against v4.x-staging would be good, we can deal with timing separate to that

Once such a pr is landed in v4.x-staging, we can generate a number of release candidates with the update that can be tested for further breakage.

Updated my initial comment with the plan / issues I'll backport. I'll get the PR worked out over the weekend, hopefully.

@saghul

@saghul it seems reasonable that this should be able to be mixed in with the v4.5.0 RC

thoughts @nodejs/lts?

@thealphanerd

@thealphanerd when is it supposed to come out?

tentatively June 14th.

Ok. I'll get the PR ASAP and we take it from there.

PR: #7205

Closing as there does not appear to be anything more to do

Navigation Menu

Repository navigation

uv: let's discuss the backport policy for LTS #6806

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

uv: let's discuss the backport policy for LTS #6806

Description

Activity

rvagg commented on May 17, 2016

Fishrock123 commented on May 17, 2016

jasnell commented on May 17, 2016

mhdawson commented on May 17, 2016

saghul commented on May 17, 2016

jasnell commented on May 17, 2016

MylesBorins commented on May 17, 2016

saghul commented on May 18, 2016

saghul commented on May 29, 2016

saghul commented on Jun 1, 2016

rvagg commented on Jun 2, 2016

rvagg commented on Jun 2, 2016

jasnell commented on Jun 2, 2016

saghul commented on Jun 3, 2016

MylesBorins commented on Jun 3, 2016

saghul commented on Jun 3, 2016

MylesBorins commented on Jun 3, 2016

saghul commented on Jun 3, 2016

saghul commented on Jun 7, 2016

jasnell commented on May 30, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions