#2402 Declare an ABI for the bindings

[Anonymous]

Originally created by: nschonni

I'm thinking we should create an ABI version number similar to the the way Node has the Module version.
I was looking at the node-pre-gyp stuff again and they use a version number as part of their example. The version number isn't a mandatory part of the binding name, but I think having something that doesn't collide between versions is a good idea.

Pros:
- If people switch node-sass versions, the vendor or cache can keep multiple binding versions and not get confused
- We can still copy/paste bindings between releases if there is not C++ changes

Cons:
- Vendor/cache will be larger if not cleaned out over time

[Anonymous]

Originally posted by: saper

I think something has to be done with sass types. It should be possible to have them in JavaScript and use whatever implementation someone wishes to use (there are many packages for CSS colors for example).

I think the binding should provide a nicer interface and he hacks we have around it in JS should go away one way or the another.

If we separate the JS/CLI part and there is a clean binary API then we have an module with its own versioning.

The only thing that remains is the underlying version of libsass - the ABI there does not seem to change often but of course different kinds of inputs are supported for SCSS and they generate different outputs.

I make extensive use of LIBSASS_EXT facility so that it is easy to double version things for me (bindings API 1.1 libsass 3.5.0 beta 2) but that's not very semver or whatever.