镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Node.js 14 - V8 version roadmap #32108

Closed
Closed

Description

@mmarchini

Looking at release dates for both Node.js and Chromium/V8 we have:

Node.js 14 initial release: 2020-04-21
V8 stable version at that date: 8.1

Node.js 14 LTS start: 2020-10-20
V8 stable version at that date: 8.5

For v12, we prepared forward-compatible patches for 7.4, and the V8 team was extra careful with ABI changes between 7.4 and 7.6 (#25082 (comment)). So based on the roadmap for v12, we would be aiming for 8.3, depending on breaking changes across V8 version. It's worth noting that we were able to upgrade v12 to 7.8, so maybe we can push further on v14 as well.

I'm working on the 8.1 upgrade and I'm seeing a few things we can make forward compatible (renaming globalThis.FinalizationGroup to globalThis.FinalizationRegistry, some C++ methods which were deprecated and are now removed, etc.). I'm not sure if there are more ABI/API breaking changes we should make forward-compatible, but with 8.2 branch cut scheduled for today we'll find out soon. It would be nice to have the same care wrt ABI changes for a few V8 versions (at least until 8.3 or 8.4), so we can upgrading V8 on v14 (cc @nodejs/v8 is that possible?).

cc @targos

Activity

  1. sam-github commented on Mar 5, 2020

    @sam-github
  2. mmarchini commented on Mar 5, 2020

    @mmarchini
    Author
  3. ryzokuken commented on Mar 5, 2020

    @ryzokuken
  4. mmarchini commented on Mar 5, 2020

    @mmarchini
    Author
  5. BethGriggs commented on Mar 5, 2020

    @BethGriggs
    Member

    The v14.x release is expected to be 2020-04-21, and promoted to LTS on 2020-10-20.

    (Just opened nodejs/Release#544 to add the specific dates to the schedule.)

  6. mmarchini commented on Mar 5, 2020

    @mmarchini
    ContributorAuthor

    Thanks @BethGriggs! I updated the issue with these dates and correct stable V8 versions based on that.

  7. joyeecheung commented on Mar 10, 2020

    @joyeecheung
    Member

    renaming globalThis.FinalizationGroup to globalThis.FinalizationRegistry

    As FinalizationGroup was only available behind --harmony-weak-refs it probably would be fine not to do anything about the renaming

  8. syg commented on Apr 6, 2020

    @syg
    Contributor

    As a heads up, I plan on removing the deprecated Isolate::SetHostCleanupFinalizationGroupCallback in M84. The FinalizationGroup hooks in C++ in node can be all removed without impacting the functionality of FinalizationRegistry today, so I recommend doing so.

  9. mmarchini commented on Apr 6, 2020

    @mmarchini
    ContributorAuthor

    Sounds good. Thank you for the heads up @syg!

  10. mmarchini commented on Apr 7, 2020

    @mmarchini
    ContributorAuthor

    In the current V8 version we have on master, SetHostCleanupFinalizationGroupCallback is not deprecated yet. Also, the method exists on Node.js v13 (and maybe earlier). @nodejs/v8-update I think we'll need to add a forward-compatibility patch deprecating this function on v14, and when we upgrade to M84 we'll need to keep this function as a no-op. Does that make sense? Alternatively, can we deprecate it on v13 and remove it on v14? Not sure how we dealt with situations like this in the past.

  11. targos commented on Apr 8, 2020

    @targos
    Member

    @mmarchini keeping it as a no-op sgtm, we already did that in the past.
    Another solution would be to backport the patch(es) that deprecated it. Is that possible?

  12. Flarna commented on Apr 8, 2020

    @Flarna
    Member

    @mmarchini I would not deprecated it in v13 as there is no replacement to use instead. Therefore users will get compiler warnings they can't avoid.

    We had something similar in the past which resulted in terrible workarounds like https://github.com/nodejs/nan/blob/2c023bd447661a61071da318b0ff4003c3858d39/nan.h#L1150-L1167

  13. targos commented on Apr 8, 2020

    @targos
    Member

    Is SetHostCleanupFinalizationGroupCallback something that native modules can really use? If not, we can remove it directly in v14.

  14. mmarchini commented on Apr 8, 2020

    @mmarchini
    ContributorAuthor

    @mmarchini I would not deprecated it in v13 as there is no replacement to use instead. Therefore users will get compiler warnings they can't avoid.

    It's an experimental feature, and the replacement is to not use the API.

    Is SetHostCleanupFinalizationGroupCallback something that native modules can really use? If not, we can remove it directly in v14.

    I'll need to investigate. According to @syg on IRC, it's unlikely a native module can use it without unwanted side effects.

  15. devsnek commented on Apr 8, 2020

    @devsnek
    Member

    A native module could in theory have used it to enable FinalizationGroups, but i find it extraordinary unlikely that such a thing happened. cc @ChALkeR for possible gzemnid analysis?

  16. tchetwin commented on Jun 10, 2021

    @tchetwin
    Contributor

    Is Node.js 14 likely to see any more "minor" V8 version updates at this stage (i.e. 8.5+)?

    Does an Issue exist similar to this one for the roadmap of V8 versions in Node.js 16? Didn't see anything referenced from #38273 (amazing stuff! 🎉)

  17. targos commented on Jun 10, 2021

    @targos
    Member

    I don't think any more V8 upgrade will be done on Node.js 14.x, so this issue can probably be closed.
    There is no specific roadmap for Node.js 16, as I am trying a new incremental approach at V8 upgrades (you can see some of the work here: https://github.com/targos/abi-stable-v8). Expect a pull request backporting #38273 very soon :)

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

    v8 engineIssues and PRs related to the V8 dependency.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions