libefp should be versioned

[susilehtola]

The shared library libefp.so should be versioned. Without sonames it is impossible for packaging systems to detect when dependencies are broken, and when any software compiled against libefp should be recompiled.

[ilyak]

Fixed in 1d4462c

[loriab]

I'd really re-open this, as I suspect no SO versioning is preferable to M.m. Below is copied from comments to the commit.

Not that I know much about SO versioning (if anyone has a link to best practices that's longer than a paragraph and shorter than a treatise, point me to it), but I've observed it changing much slower than API versioning. And if core things like /lib64/libc.so.6 glibc have only made it to 6 and haven't used minor, I don't think libefp needs it.

@bennybp, do you know the conventions?

[ilyak]

No, most libs have major.minor or major.minor.patch. Check libc.so.6 on your system - it is probably a symlink to something like libc-2.12.so

[loriab]

Right, I'm all for major.minor.patch.tweak dev/post/beta, etc. for API versioning (2.12 for glibc). But the SO versioning this issue brought up is different and reflects the ABI version (6 for glibc). https://autotools.io/libtool/version.html is helpful. I can see why SO version is appealing to package maintainers, but providing the SO version means evaluating and guaranteeing a whole further layer of compatibility beyond the purported package version.