SONAME handling

[svillemot]

The SONAME of openspecfun is currently libopenspecfun0.3.0. In other words, it contains the version number.

This is not good practice. The SONAME should not follow the same sequence as version numbers. The SONAME should only change when the ABI changes in a backward-incompatible way.

The practical consequence of having the SONAME equal to the version number is that all binaries linked against openspecfun will have to be recompiled everytime there is a new openspecfun version. In other words, it is almost as if openspecfun was only available as a static library. This is particularly painful for Linux distributions.

Would it be possible to move to a more standard SONAME handling? Of course, this implies that you must track ABI changes and increment the SONAME if there is a backward incompatible ABI change.

[nalimilan]

Oops, I hadn't noticed that when packing openspecfun. I think this is just an oversight.

The version used to be only the first digit, and then @staticfloat changed it to three digits in https://github.com/JuliaLang/openspecfun/commit/37c2cc18fe9f71923a423ae1afdfdf8439e192d5. But he also added the logic needed to extract only the first digit, which is used to set the .so filename. It should be easy to set the SONAME to include only the first digit: just replace libopenspecfun.$(SHLIB_EXT).$(VERSION) with libopenspecfun.$(SHLIB_EXT).$(word 1,$(VERSION_SPLIT)), which is what is used for the name of one of the .so files. Preparing a pull request.

[svillemot]

@nalimilan Thanks, this is helpful.

However note that using the major version number in the SONAME means that major releases have to be tied to backward-incompatible ABI changes. In particular, if you stick to that scheme, this means that openspecfun 1.x will have to be released if a single function is removed. Or that you cannot bump to openspecfun 1.x if you add tons of new functions without removing/ABI-changing any.

[svillemot]

Said otherwise, I think that the right fix is not to use the major version number, but a new Makefile variable called SOVERSION, that is incremented if and only if there is a backward incompatible ABI change.

[staticfloat]

This seems reasonable. Pinging @ViralBShah as well. Even though we don't change these projects that much, I think it's best to be as good a citizen as we can be. I'll submit a PR.

[ViralBShah]

I agree - we should certainly be good citizens.

[svillemot]

Given the discussion in JuliaLang/openspecfun#20, I therefore agree with the changes proposed by @nalimilan

[svillemot]

Fixed in 13edeedc0ce1a49be9218617a9bdb74e90084d51.