libefp should be versioned about libefp

[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.