Reconsider ABI stability requirement for V8 updates in majors

[RafaelGSS]

Opening this to discuss whether we should stop treating ABI compatibility changes as blockers for V8 updates in major releases.

We’ve been hitting the same issue repeatedly. v26.0.0 was already delayed for V8 14.6, and that version became outdated almost immediately with Chrome 148 (V8 14.8) going stable.

From the TSC thread, the main pain point is that ABI stability adds pressure and slows down landing V8 updates. Removing that constraint would let updates land when they’re actually ready instead of forcing timing compromises.

There was also the suggestion to drop ABI stability guarantees in majors and push the ecosystem more toward N-API or FFI.

This is probably too late for v26, but could make sense starting in v27.

cc: @targos, who has handled most (if not all) V8 updates for quite a long time

[richardlau]

There was also the suggestion to drop ABI stability guarantees in majors and push the ecosystem more toward N-API or FFI.

FTR the suggestion to drop ABI stability was made separately from (my) suggestion that if we do that the policy shift should happen in a major. We do include the V8 headers in the Node.js header tarball for addons so it needs to be clearly communicated if we make the change.

[joyeecheung]

In general I am in favor of decoupling ABI versioning with Node.js semantic versioning, though I don't think it's the same as "dropping ABI stability" - which implies we no longer version the ABI at all.

To me it seems being able to bump a new ABI version in the lifetime of a Node.js major release at least before it goes LTS would be enough as a relief and is relatively low risk - most addon prebuild tools are already pre building based on ABI versions, not Node.js versions. But not having versions for breaking changes in the ABI would be too disruptive.

[aduh95]

Worth noting that, as of Node.js 27, we'll be releasing versions before 27.0.0 which might include semver-major changes, and possibly ABI-breaking changes – the intent being explicitely that we want to bump the V8 version before releasing 27.0.0.
IIUC the proposal is to extend that to the "Current" phase? And LTS as well?

[mcollina]

I think we should define where we stop.

1. allow V8 majors in current
2. allow v8 majors in LTS
3. allow V8 majors in maintenance

Personally, I'm very comfortable in having them in current, a bit less so in LTS, and as an "absolutely not" in maintenance.

[RafaelGSS]

Worth noting that, as of Node.js 27, we'll be releasing versions before 27.0.0 which might include semver-major changes, and possibly ABI-breaking changes – the intent being explicitely that we want to bump the V8 version before releasing 27.0.0. IIUC the proposal is to extend that to the "Current" phase? And LTS as well?

That's right. I guess we won't have to delay semver-majors release anymore during the Alpha version. Theoretically, V8 14.6 could be released from April 22th until Oct Xth, which should make the process much easier.