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.