Repository navigation
Breaking ABI on an existing release line by bumping NODE_MODULE_VERSION #49875
Description
Activity
cc @nodejs/tsc
Given that v16 is out of support, I'm +1 with the ABI breakage before v20 hits LTS.
I don't think we should backport this to v18.I do believe this is going to break prebuilt native addons if they are not using Node-API. I don't think we should be doing this unless we have something that is
really reallyimportant enough to override respecting SemVer.In terms of v20, developers to have worked in advance to create their prebuilt addons for 20.x are likely to be unimpressed if we break then just a few weeks before the LTS switch.
@joyeecheung have you got a tracking issue for the breaking of Jest? What % of users are affected?
So I just realized that since we can "add whatever we want to the v8 fork on v20.x", basically, we can use some Node.js-only extensions to the V8 API there to avoid the ABI breakages completely. Not sure if we should still keep the issue open though, as ABI breakages might still come up again, maybe we need to update the doc about whether this is feasible or not..
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
According to
node/doc/contributing/releases.md
Line 1210 in f16f41c
Now the time comes when we may need to break the ABI in order to backport to v20.x a series of memory issue fixes that are blocking people (in particular jest users) from upgrading away from v16.x: #49874 .EDIT: turns out that we found a way to avoid the ABI breakage.
This issue is used to figure out