Instantly share code, notes, and snippets.

@maxogden /readme.md
Last active Oct 30, 2015

Embed
What would you like to do?
node.js release questions

As a maintainer of native node add-on modules I have some questions about when and why NODE_MODULE_VERSION changes:

(@rvagg has anwered these in the comments below)

  • does v8 use semver? how do you know when a v8 version breaks ABI compatibilility?
  • is there a semantic meaning for v8 version numbers or is it arbitrary?
  • who maintains this google doc I found? is it official?
  • why is the latest entry from may in the v8 changelog? https://chromium.googlesource.com/v8/v8.git/+/master/ChangeLog
  • how can you tell when all these future v8 versions will be stable? https://chromium.googlesource.com/v8/v8.git/+refs
  • why must a node major version correspond to a specific v8 version? e.g. node v5 uses v8 4.6 and won't upgrade to 4.7
  • follow-up from last question: assuming v8 4.6 and 4.7 are ABI compatible (according to above google doc), why can't node v5 minor versions use v8 4.7?
  • will a new breaking change in v8 always correspond to a new major version of node?
  • if a major version of node gets released, and the next week a new stable version of v8 gets released with breaking ABI changes, will node users have to wait 6 months for a stable release with the new v8?
  • are there any other reasons besides v8 upgrades that cause NODE_MODULE_VERSION to increase?
@rvagg

This comment has been minimized.

rvagg commented Oct 29, 2015

does v8 use semver? how do you know when a v8 version breaks ABI compatibilility?

V8 uses GoogleVer which is kind of arbitrary, currently they are tracking Chromium release numbers so V8@4.4 -> Chromium@44, V8@4.5 -> Chromium@45, perhaps that'll continue but all you should care about is that they cut a new minor (in the semver sense, this is not semver) for a new version of Chromium.

is there a semantic meaning for v8 version numbers or is it arbitrary?

They call it major.minor.patch.build, in core we pin to major.minor and the others we treat as arbitrary. Try not to make too much sense of this.

who maintains this google doc I found? is it official?

The V8 team maintain this, it's official and they are getting better at communicating future breakages (I'd like to attribute that to Node putting the pressure on!)

why is the latest entry from may in the v8 changelog? https://chromium.googlesource.com/v8/v8.git/+/master/ChangeLog

Use the GitHub mirror instead: https://github.com/v8/v8 I also have a tool to fetch and sanitise the changelog, v8-changelog in npm: https://github.com/rvagg/iojs-tools/tree/master/v8-changelog

how can you tell when all these future v8 versions will be stable? https://chromium.googlesource.com/v8/v8.git/+refs

There's probably a better answer to this but generally we wait for them to announce their new version when they cut a branch. The branches exist for a period of time until the corresponding version of Chromium goes stable. e.g. v4.6 was unstable until Chromium v46 went stable so it became usable. Node.js won't ship anything unless it's in a stable version of Chromium.

why must a node major version correspond to a specific v8 version? e.g. node v5 uses v8 4.6 and won't upgrade to 4.7

Almost entirely because of the C++ API breakage problem. A hard lesson we learnt in io.js was that every time we shipped a new V8 it broke the npm ecosystem and that's painful. The V8 team don't feel as much need to keep their API stable and even where it is stable (like in 4.5 -> 4.6) the ABI is not stable, so stuff just breaks and at a minimum you need to recompile your addons but at worst we need to ship a new NAN and have you update your code to make it work. Our compromise is to disconnect from their 6-week cycle cause it'd be too painful to do otherwise.

follow-up from last question: assuming v8 4.6 and 4.7 are ABI compatible (according to above google doc), why can't node v5 minor versions use v8 4.7?

They are not ABI compatible, there are minor changes in there. I don't believe we've ever seen an ABI compatible V8 between Chromium versions. It's not a priority for them and we're pretty much the only users that complain. Thankfully relationships are getting better and and we are seeing change but ABI stability does not appear to be on the radar at all.

will a new breaking change in v8 always correspond to a new major version of node?

Yes, that's the policy we adopted because we're now considering C++ API breakage (even with NAN bridging the gap) to be a breaking change, but that's why we're not going to ship them all.

if a major version of node gets released, and the next week a new stable version of v8 gets released with breaking ABI changes, will node users have to wait 6 months for a stable release with the new v8?

Yes. But we are going to be shipping master/canary/unstable builds, we just don't have a strategy for this yet. It's going to be a crazy ride for anyone that uses them and there'll likely be a ton of addon breakage if you opt for this so it won't be for people who just need to get stuff done.

@rvagg

This comment has been minimized.

rvagg commented Oct 29, 2015

are there any other reasons besides v8 upgrades that cause NODE_MODULE_VERSION to increase?

Yes, in the past there have been core C++ API/ABI changes, a recent example is the Buffer changes but that was forced by V8.

But, we are now restricting NODE_MODULE_VERSION to only be incremented in line with semver-major bumps, so it'll be stable for 6 months and even longer on LTS releases. So every semver-major is held up in the core repo until the next major and we avoid shipping anything that would force a NODE_MODULE_VERSION bump in between.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment