Skip to content

Libuv v1.x maintenance #1657

Closed
Closed

Description

@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 >:-(

Activity

  1. aduh95 commented on Nov 27, 2024

    @aduh95
    Contributor

    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).

  2. mcollina commented on Nov 27, 2024

    @mcollina
    SponsorMember

    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).

  3. bnoordhuis commented on Nov 27, 2024

    @bnoordhuis
    MemberAuthor

    When is the libuv v2 ETA?

    No ETA yet.

  4. gireeshpunathil commented on Nov 27, 2024

    @gireeshpunathil
    Member

    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.

  5. richardlau commented on Nov 27, 2024

    @richardlau
    Member

    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.

  6. bnoordhuis commented on Nov 27, 2024

    @bnoordhuis
    MemberAuthor

    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.

  7. saghul commented on Nov 27, 2024

    @saghul
    Member

    See the linked issue for the ongoing discussion.

  8. mhdawson commented on Dec 2, 2024

    @mhdawson
    Member

    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

  9. mhdawson commented on Dec 2, 2024

    @mhdawson
    Member

    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.

  10. joyeecheung commented on Dec 19, 2024

    @joyeecheung
    Member

    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..

  11. jasnell commented on Jul 18, 2025

    @jasnell
    Member

    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?

  12. bnoordhuis commented on Jul 21, 2025

    @bnoordhuis
    MemberAuthor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions