Libuv v1.x maintenance

[bnoordhuis]

Context: libuv/libuv#4622

Node.js still considers libuv an essential component? Because I've got news!

A number of libuv maintainers have expressed the desire to release libuv v2. That's a conundrum for node LTS because v2 won't be API- or ABI-backwards compatible and we're not going to support v1 until 2027 or 2028, or whenever the last v1-based LTS goes EOL.

I think that leaves a few options for node:

1. Do nothing. Pro: cheap. Con: bugs and vulnerabilities go unfixed

2. Take v1 maintenance in-house. Won't be under the libuv org's umbrella so you'll have to figure out all the logistics yourself

3. Persuade maintainers with money to keep maintaining v1.x as long as is necessary

To set expectations: this is a courtesy call, not an invitation to discuss what libuv should or shouldn't do. Every time someone posts a comment with a vibe of "you are morally obliged to" my hourly rate doubles >:-(

[aduh95]

EOL for 22.x is scheduled for 2027-04-30, which, assuming we're able to upgrade to libuv v2 before 24.0.0, should be the last release LTS line with libuv v1.

Whichever of the three options we take, I'd be in favor of cutting 22.x support short, e.g. either set it at the same time as 20.x EOL (on 2026-04-30), or at the same time as 24.x will transition to Maintenance (on 2026-10-20).

[mcollina]

Thanks for the courtesy call!

When is the libuv v2 ETA? Could it be shipped before March 2025, so it can land in Node.js v24?

My 2 cents is that we should keep maintaining libuv v1 in tree in the Node.js project for the LTS branches and backport whatever security fixes are needed there for the LTS branches. If/when we need a specific backport for a bugfix, we would call for volunteers.

@marco-ippolito @ljharb, are those (potential) security backports something that HeroDevs could take care of? You'll need to do the work anyway.

I'm +1 to cut the v22 maintenance window shorter than when v24 enters maintenance (2026-10-20).

[bnoordhuis]

When is the libuv v2 ETA?

No ETA yet.

[gireeshpunathil]

is there a way I can see all the v2-bound features? I thought there was a v2-candidate branch or PRs labelled as v2, but couldn't find either.

[richardlau]

My 2 cents is that we should keep maintaining libuv v1 in tree in the Node.js project for the LTS branches and backport whatever security fixes are needed there for the LTS branches. If/when we need a specific backport for a bugfix, we would call for volunteers.

As a data point, while all of the supported Node.js releases lines are on libuv v1, not all of them are on the most recent. Node.js 18 is currently still on libuv 1.44.2 (due to regressions seen on Node.js 20 with later libuv versions, see nodejs/node#50036) and nodejs/node#51702 backported the fix for GHSA-f74f-cvh7-c6q6 to it. (Without checking I don't know if it's feasible to update now -- at one point libuv dropped support for older macOS versions that Node.js 18 technically still supported.)

I'm -1 on changing the lifecycle of Node.js 22 now that it's LTS. The whole point of LTS is to have a known lifecycle you can plan around, and we should only be changing as a last resort.

[bnoordhuis]

is there a way I can see all the v2-bound features?

Look at libuv's master branch. There will likely be more backwards incompatible changes before the release though.

[saghul]

See the linked issue for the ongoing discussion.

[mhdawson]

I'm -1 on changing the lifecycle of Node.js 22 now that it's LTS. The whole point of LTS is to have a known lifecycle you can plan around, and we should only be changing as a last resort.

I agree, should try to keep to the planned LTS lifecyle

[mhdawson]

On the assumption that there would be no updates for v1 I'd agree with @mcollina's suggestion:

My 2 cents is that we should keep maintaining libuv v1 in tree in the Node.js project for the LTS branches and backport whatever security fixes are needed there for the LTS branches. If/when we need a specific backport for a bugfix, we would call for volunteers.

[joyeecheung]

It still feels a bit early with libuv v2 ETA still not decided, but once it's decided I think a general way forward is:

1. The main branch should be updated to v2 soon-ish
2. Existing release branches obviously have to stay with v1, due to ABI compatibility
3. In the meantime, libuv v1 on existing release branches are maintained by Node.js, similar to the V8 situation.
4. If there are any security vulnerability/critical bugs from libuv happening to the release branches with v1, we call for volunteers.
5. If there is lack of volunteers, we try to get help from HackerOne/Alpha-Omega (if it's security) or from whatever funds that are available to fund fixes by libuv maintainers (I think only Sovereign Tech Fund is available for now, but we are not even sure if there's any money left for Node.js to contract someone to improve the CI, and maybe HeroDevs too? but not sure how much of that is available to the project to fund any engineering work).

Generally 4-5 wouldn't be to different from whatever that happens to Node.js's own bugs, if the bug in libuv affects Node.js then I imagine how it works is that it ends up on the radar of TSC somehow, and the TSC might request some budget from the CPC if it's deemed to be prioritized over other issues in Node.js that also need funds.

Cutting the LTS short doesn't seem necessary, this just puts libuv in the same situation as V8, unless libuv v1 is somehow more bug-prone than all the years-after-EOL V8 versions we maintain in the LTS..

[jasnell]

This issue is still likely relevant but there's been no activity for the past six months. Have their been any relevant updates? Should we just keep this issue open indefinitely? Any suggestions as to concrete next steps?

[bnoordhuis]

I'm okay with closing this. Nothing much will probably happen in the next few months anyway because of summer holiday.