Freezing deps/v8 on the main branch during major V8 upgrades

[joyeecheung]

While working on #65161 which will upgrade deps/v8 from 14.6 to 15.2 on the main branch I've noticed a pattern - there have been many commits being backported to deps/v8 the main branch while the upgrade is happening, but these backports are actually causing mostly trouble rather than helping anything because:

1. The release branches have much older versions of V8, so these commits likely need to be adapted again to even older V8 releases if they want to go out ASAP, then the rewrite targeting the main branch is therefore not very useful
2. Most of these commits are already in 15.2, so they'll be overwritten by the upgrade anyway. However because they land too early on main, whenever this happens it creates a conflict for the 15.2 upgrade and we had to spend some energy to figure out if it needs to be skipped or re-applied (usually it just needs to be skipped)

Based on these observations I think in general, when there's a big V8 upgrade pending on the main branch (say we are jumping more than 2 major versions), it's usually counterproductive to try backporting anything to deps/v8 on the main branch until the upgrade lands. If the intention is for the backport to go out on a release, the contributor should be redirected to backport that V8 commit to release branches, not main.

Opening this issue to see if others agree and we can settle down on a more formal policy on this to reduce future churn.

cc @nodejs/tsc @nodejs/v8-update

[richardlau]

I think I'm generally in favour, but how do we ensure the V8 updates on main don't cause regressions as the backports won't be on there?

[joyeecheung]

Another stricter option: with the exception of changes that smooth over upgrade breakages and build failures, it may be counterproductive in general to backport any bugfix/feature to deps/v8 on main, given that we are almost always behind the v8 release schedule for quite a bit, and V8 has now moved to release every 4 weeks. The time it takes for a V8 commit that's already in lkgr to end up in a V8 stable release is likely even shorter than the time it takes for a V8 commit on Node.js main branch to end up in a Node.js release. Hence in general if the intention is to make a V8 change available to users via Node.js releases, not just fixing something temporarily in the main branch, V8 backports should be redirected to release branches.

[joyeecheung]

but how do we ensure the V8 updates on main don't cause regressions as the backports won't be on there?

There would only be regressions if the backport steps ahead of the V8 upgrade:

1. The commit is already in V8 lkgr, but not yet in a stable V8 release
2. The commit is in a stable V8 release, say N, but on the main branch we are still trying to upgrade to M < N

I think in both cases, it's only a matter of time for the commit to flow into main as we finally upgrade to the V8 release that include the commit. If people don't fast track the backport, there couldn't be regressions on the main branch to begin with - it only goes from "not working -> working again"; "not working -> working after a fast-tracked backport -> not working because overwritten by an upgrade -> working again after re-applied" is not possible if we just stop the second step (and if we don't stop the fast track, the risk is always there, because in the V8 upgrade we already have to double check when conflicts happen due to fast track, it relies on someone to meticulously check this, but there's no guarantee that the commit won't be missed out already. we might as well never count on a fast track to work).

[aduh95]

The release branches have much older versions of V8

Node.js 26 and main share the same version atm FWIW

[mcollina]

We might conclude that we are issuing V8 backports direactly against the -staging branch? I think the only reason they went to main was because they had the same version.

[joyeecheung]

We might conclude that we are issuing V8 backports direactly against the -staging branch? I

Yeah the more I think about it, the more I find that for V8 bug fix/features, it doesn't really make a lot of sense to backport to main. If it's already in the V8 upstream, it should only be a matter of time for it to flow into the main branch, and as V8 shortens the release span to 4 weeks, generally it's not really very meaningful to fast track at the expense of V8 upgrade conflicts. The more we backport to main, the more likely that we are going to keep delaying V8 upgrades and falling behind due to the churn. If we generally try to reduce the churn it's more likely for us to follow up with V8 releases more quickly.

[Renegade334]

A caveat to that is where V8 commits are cherry-picked for a specific API feature or behaviour visible to the embedder, eg. d66c3a6, then landing on anything other than main is meaningless.