Node: Next convenient date for an ABI breakage?

Created on 19 Dec 2017 · 9Comments · Source: nodejs/node

Hard-coded constants in v8.h for instance types have been frequent sources for ABI breakages, when they change. Whenever we introduce a new instance type in V8, ones that come after the new type in the instance type list get bumped up, thus requiring change to the hard-coded constants.

Recently, we have extended the instance type field from 8 bits to 16 bits. So we have a lot more room for instance types. To prevent frequent ABI breakages, we could reserve some space for future instance types so that introducing new ones do not lead to ABI breakage. To do that however, we would need to break the ABI once.

Is there any convenient point in time to do that?

V8 Engine question

Source

hashseed

Most helpful comment

IMO the sooner the better, preferably before the version that we will include in Node 10 (should be 6.5 or 6.6 depending on the timing).

targos on 19 Dec 2017

👍3

All 9 comments

IMO the sooner the better, preferably before the version that we will include in Node 10 (should be 6.5 or 6.6 depending on the timing).

targos on 19 Dec 2017

👍3

Yeah, I agree. Bumping V8 in Node 9 is probably not worth the effort, but it’s something we’ll want for Node 10 if we can get it.

addaleax on 19 Dec 2017

Comments welcome: https://chromium-review.googlesource.com/c/v8/v8/+/833874

hashseed on 19 Dec 2017

+1 to what everyone has said... doing it before 10.x would be most convinient

MylesBorins on 19 Dec 2017

+1 on ASAP.

Perhaps we can generalize this into a wish: Generally speaking for even-numbered releases I think we probably want to be pickup new versions of V8, so we would prefer ABI stability (or easily patchable ABI differences) for the 'baking' period of those release lines. For Node 10 this would generally be the Feb-ish - Aug-ish timeframe. Immediately after an odd-number release is cut is probably the best time to make ABI changes in V8.

ofrobots on 19 Dec 2017

Yes, before 10.0.0 would be best. So you know, I plan to cut the working v10.x branch around early to mid March, with a goal of beginning to reduce the semver-majors pulled in by April 1st. I will be looking to cut the 10.0.0 release the last week in April. My goal is to have at least two release candidates cut. I think that, ideally, whatever ABI changes are necessary here will sit in master for at least two months cutting the 10.0.0 release.

jasnell on 19 Dec 2017

One thing to keep in mind is that V8 branches a release line ~12 weeks before it goes stable. This means that the version of V8 that is intended to go into 10.0 will branch around three months before the release date for 10.

ofrobots on 19 Dec 2017

I'm also +1 on doing this ASAP (already LGTMed the upstream CL) given the information we have now.