On 28/07/2012 15:24, Jakob Kummerow wrote: > Only one remark, which is not node.js specific at all: > > As has been discussed previously in this thread, V8's version numbers > do not try to make any statements about binary compatibility. That > means to avoid run-time breakage, *any* applications compiled against > V8 must play it safe and depend on *exactly* the V8 version they were > compiled against. > > When you're *lucky*, something that's compiled against, say, V8 > v3.11.10.17 will also work with v3.11.10.18, but there are *no > guarantees* that all 3.11.10.x versions are ABI compatible. (Most of > the time they are, because most stability/security fixes do not > change the ABI, but sometimes they're not, because when we decide to > backport a fix we do not even check for ABI compatibility.) > > When you let your node.js package depend on "V8 >= 3.11.10", it again > comes down to luck: If you are careful to release matching updates > for both packages at the same time, and if all of your users happen > to always install matching sets of updates, everything will be fine. > If, however, for whatever reason someone ends up with the older > node.js package and e.g. V8 3.14.x, chances are their node.js will > not work. (Again, no guarantees either way -- it might happen that > our ABI won't change between 3.11 and 3.14, or that at least it > doesn't break backwards compatibility, but nobody is ensuring this or > even trying.) If my package manager installed two packages on my > system which are not compatible given their respective versions, I > would consider that a bug ;-)
I agree with you, that is why using an ABI compatibility checker is indispensable when i suggest to use major.minor.build soname version. Otherwise one would have to do as you say. Jérémy. -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
