Node.js 12 - V8 version roadmap

[hashseed]

From available release dates for both Node.js and Chromium/V8, we deduce the plan for upgrading V8:

Node.js 12 initial release: 2019-04-23
V8 stable version at that date: 7.4

Node.js 12 LTS start: 2019-10-XX
V8 stable version at that date: 7.7 or 7.8

So at the time of the initial release, we will use V8 7.4, but with a floating patch to be forward-compatible with 7.5. We will then upgrade to 7.5 when it becomes stable. We will later upgrade to 7.6 with a floating patch to be backward-compatible with 7.5.

We stop at 7.6.

So the V8 team will be extra careful between 7.4 and 7.6 wrt ABI stability. Any feature Node.js needs V8 to implement for Node.js 12 will need to land in 7.6 or earlier.

@psmarshall @targos @nodejs/v8-update

[hassan-dev]

From available release dates for both Node.js and Chromium/V8, we deduce the plan for upgrading V8:

Node.js 12 initial release: 2019-04-23
V8 stable version at that date: 7.4

Node.js 12 LTS start: 2019-10-XX
V8 stable version at that date: 7.7 or 7.8

So at the time of the initial release, we will use V8 7.4, but with a floating patch to be forward-compatible with 7.5. We will then upgrade to 7.5 when it becomes stable. We will later upgrade to 7.6 with a floating patch to be backward-compatible with 7.5.

We stop at 7.6.

So the V8 team will be extra careful between 7.4 and 7.6 wrt ABI stability. Any feature Node.js needs V8 to implement for Node.js 12 will need to land in 7.6 or earlier.

@psmarshall @targos @nodejs/v8-update

cool

[targos]

@hashseed You told me a few months ago that V8 would like to bump the C++ compiler requirement to full C++14 support. It means that Node.js must bump GCC to at least version 5 (we currently support >= 4.9.4).
In yesterday's TSC meeting, concerns were raised that it might be difficult to adapt the build infrastructure for that change before the release of Node 12.
Do you have an idea about which version of V8 would really require full C++14 support? Can we assume that 7.6 will be safe and make the build changes for Node 13 (so, that would be V8 7.7 or 7.8)?

[targos]

Ping @hashseed ^

[hashseed]

The toolchain we test with already supports C++14 if I'm not mistaken, so during development it won't be easy to detect those issues. That said, if they do occur, we can certainly roll offending changes back or work around Node.js' limitations.

[richardlau]

From available release dates for both Node.js and Chromium/V8, we deduce the plan for upgrading V8:

Node.js 12 initial release: 2019-04-23
V8 stable version at that date: 7.4

Not sure if the dates have slipped since this was first posted, but the current https://www.chromium.org/developers/calendar has V8 7.4 estimated going stable in the week of 23 April 2019:

This doesn't seem to line up neatly with the Node.js 12 plan (nodejs/Release#417) -- For example we're aiming to have release candidates from March 23rd so this either means we need to merge V8 7.4 into the Node.js 12 proposal branch before it goes stable or we drop it in at the very last moment which does not sound like a good idea to me.

cc @nodejs/release @BethGriggs

[targos]

I am in favor of merging V8 7.4 before it's stable. But we would need the API compat patch with 7.5 very soon.

[addaleax]

@targos Hey! If you want, I can look into preparing a V8-7.4-to-V8-master compatibility patch today?

[hashseed]

Please loop in @psmarshall!

[targos]

@addaleax Thank you :). I'm going to prepare the pull request for V8 7.4 tomorrow with @ryzokuken. I don't know if it's easier for you if you have a branch to target?

[targos]

I'd also like to propose that we remove from V8 headers all APIs that are marked as deprecated. WDYT ?

[addaleax]

@hashseed @targos The diff seems rather small, but it’s mostly ABI changes coming from pointer compression, in particular v8/v8@392316d. That applies cleanly on V8 7.4, but it looks like something where we’d have to check that it is actually applicable?

[Flarna]

I'd also like to propose that we remove from V8 headers all APIs that are marked as deprecated. WDYT ?

I would expect that this breaks a lot native addons which currently work fine and don't care about warnings issued.

[hashseed]

V8's policy is that we may remove deprecated APIs from one version to another. This would mean that APIs marked as deprecated in 7.4 or 7.5 may disappear in 7.6, and Node would have to float one or more reverts, which may not be trivial.

[mhdawson]

@hashseed or not pickup 7.6 ....

[hashseed]

That's true. But considering that you'd have to update these node modules for Node 13 or 14 anyways because the V8 API will be long gone by then, does it make too much of a difference?

[richardlau]

If things were marked deprecated in V8 7.0 (Node.js 11) then addons authors will have had a Node.js release cycle to notice the warnings. (Although some modules only officially support LTS releases of Node.js for which the base is V8 6.8).

If things were only marked deprecated in V8 7.1 and later then addons authors have had no warnings if those things are suddenly removed in Node.js 12.

[Flarna]

I think most addons available for several node versions use anyway NAN. There are a lot addon users out there where warnings are a no-go, therefore NAN will be adapted fast to not use deprecated functions independent if they issue warnings or are missing completely.

What should be avoided in my opinion is to change the deprecation status within a major version as this just results in a set of pragmas in NAN to silence them without breaking ABI (see nodejs/nan#833, #23159) and the initial intention is lost.

But sure, for some addons removing deprecated functions will speed up their death...

[richardlau]

NAN doesn't cover all the V8 APIs though, just the common cases. But perhaps the set of modules that need to interact directly with V8 APIs not covered by NAN would be limited to diagnostics tools and the like?

[Trott]

Now that 12.0.0 is out, should this be closed? Or should it remain open until 12 goes LTS in October (in which case I'll leave it open but remove it from the 12.0.0 milestone)?

[hashseed]

I'd like to keep this open for the next two V8 version bumps within 12

[targos]

V8 7.6 landed in v12.9.0. We might still be able to do a last upgrade to 7.7 before LTS. I opened #29241 for that.

[Whobeu]

I am crossing my fingers that 7.8 makes it into either Node 13 or 14. I am really looking forward to Optional Chaining and Nullish Coalescing. Patches for them have already been applied to 7.8 as they are at Stage 3.

[GaryGSC]

V8 7.8 made it into Node 13.

And... there's now an in-progress PR to backport V8 7.8 to Node 12. 🎉

[mmarchini]

V8 7.8 made it to Node.js v12, and it's unlikely we'll get 7.9 on v12. Can we close this issue?

[mmarchini]

Closing, but if someone wants to try and backport 7.9 to v12, feel free to do so.

[Whobeu]

I'd love to see V8 8.0 on Node 14 so I do not need to use harmony flags for Optional Chaining and Nullish Coalescing. Guessing Node 15 would be the earliest at this point unless there is a backport effort on Node 14. Node.green reports Node 14 is 70% ES2020 compliant without harmony flags. That rises to 94% with harmony flags.

[mmarchini]

@Whobeu v14 will likely ship with V8 8.1.