shared-library versioning

[stevengj]

We should really include a version number in the shared library (this is different from the utf8proc source version: the source version indicates API compatibility, while the library version encodes ABI compatibility). I have used libtool for this in the past, but the whole autotools stack is probably not worth the trouble here (although we could use just the libtool script, which could be bundled by make dist).

[stevengj]

See also the discussion of a soname in the Fedora package. cc: @nalimilan

[nalimilan]

Great! Note that by choosing 1.2.0, you signal an ABI break as compared with the 0.1 SOVERSION I have used in the Fedora package. Is that intended?

[stevengj]

Yes, that is intended. The ABI has changed incompatibly because a struct was changed by #20 (although the API is backwards compatible). It will probably change again once #2 is fixed, which is one reason I'd like to do that before we release.

Of course, since this is the first release with a soname, I could have chosen 1.0.0 or even 0.0.0 (though Darwin doesn't like zero versions), but I figured it was less confusing to start with a version that matches the API version (even if they subsequently diverge).

(Note that technically the ABI version is 1 ... the 1.2.0 is not in the soname.)

[nalimilan]

OK, perfect. Indeed, following the API version when possible is a good idea. Ideally ABI and API will only be broken at the same time in the future, and both versions incremented together.