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_VERSIONto increase?
V8 uses GoogleVer which is kind of arbitrary, currently they are tracking Chromium release numbers so [email protected] -> Chromium@44, [email protected] -> 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.
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.
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!)
Use the GitHub mirror instead: https://github.com/v8/v8 I also have a tool to fetch and sanitise the changelog,
v8-changelogin npm: https://github.com/rvagg/iojs-tools/tree/master/v8-changelogThere'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.
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.
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.
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.
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.