Updating libuv on 8.x and 10.x

[MylesBorins]

I believe that certain versions were not backported to 10.x or 8.x as there was an unexpected semver-major

we can use this issue to track status and backporting

/cc @nodejs/libuv @cjihrig @addaleax

[cjihrig]

Copying #19455 (comment) regarding accidental breaking changes here in case it helps:

I think you're referring to #22814 and #21203. Both of those issues are fixed. A regression test for #22814 landed in #23051. #23053 fixed #21203, but it's marked as don't land on v10 and earlier. Now, that might be backportable since it reverts a semver major and the version of libuv can now be updated on those older branches

[bnoordhuis]

What Colin said. There were bugs (there are always bugs) but no (edit: deliberately) backwards incompatible changes.

[AndrewGuenther]

Just to be clear, is it still the plan to backport updates to libuv to 8.x? I ask because a recent update to libuv on 10.x broke compatibility with older kernels. Relevant commits:

2790db5
c65a523

Does it make sense to introduce this change to 8.x? We've migrated a lot of our services to 8.x since it entered active LTS and this change would force us to roll back hundreds of services to 6.x so that we could continue to get security and stability updates.

I guess my confusion comes from what it means to be "Active LTS." Should these kinds of changes be expected in an active LTS?

[MylesBorins]

These changes will only be backported if it can be done in a non breaking way, that is why it has not yet happened

…

On Wed, Oct 24, 2018, 12:54 PM Andrew Guenther ***@***.*** wrote: Just to be clear, is it still the plan to backport updates to libuv to 8.x? I ask because a recent update to libuv on 10.x broke compatibility with older kernels. Relevant commits: 2790db5 <2790db5> https://github.com/nodejs/node/blob/c65a523597ccdf2b3544244679dae581040cf52f Does it make sense to introduce this change to 8.x? We've migrated a lot of our services to 8.x since it entered active LTS and this change would force us to roll back hundreds of services to 6.x so that we could continue to get security and stability updates. I guess my confusion comes from what it means to be "Active LTS." Should these kinds of changes be expected in an active LTS? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#23833 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecVxhAQxBkjwD7Zm8BhqSTLqXgLQ-Zks5uoJtKgaJpZM4X14Vr> .

[AndrewGuenther]

Excellent. Thanks for the clarification @MylesBorins! So would you say that, in general, we shouldn't have to worry about these kinds of changes during Active LTS?

[bnoordhuis]

The minimum requirement for v8.x is linux 2.6.32 so no problem there, that's what libuv supports.

v6.x supports 2.6.18 and would be problematic but that's not being discussed, right?

[MylesBorins]

V6.x is now in maintenance mode and there is no plan to update libuv

…

On Fri, Oct 26, 2018, 2:58 PM Ben Noordhuis ***@***.*** wrote: The minimum requirement for v8.x is linux 2.6.32 so no problem there, that's what libuv supports. v6.x supports 2.6.18 and would be problematic but that's not being discussed, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23833 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecVxcbf_utVt_GJFPNt4lPYPxNPZNoks5uo1tWgaJpZM4X14Vr> .

[Trott]

@MylesBorins Should this remain open?

[AndrewGuenther]

This upgrade has landed in 8.x now and has broken compatibility with older kernels:

62dd1d7

Systems which could previously run 8.x, which is in LTS, now cannot run 8.x.

[MylesBorins]

@AndrewGuenther can you please open an issue to track this along with a description of how to replicate the breakages. If the broken runtime is with our support matrix we will work on getting a fix out asapc

[AndrewGuenther]

Will do. Happy Thanksgiving!