drhpc
commented
2 years ago You could jump to libscalapack.so.3.0.1 to indicate that you have a new ABI, but it still is compatible with the so.2 … I am not sure how often that is used, though. And I'm totally ignorant on how you'd do that with CMake. Libtool does that stuff traditionally;-)
48 adopted a versioning policy for the shared library, to use libscalapack.so.MAJOR.MINOR, implying a (possible) ABI break with each minor ScaLAPACK release. Since this is yet not part of a release, I suggest considering a more conservative approach that avoids needless breakage of user binaries on library updates.
Personally, I use semantic versioning for projects, incrementing the minor version for feature additions. The project version is distinct from the version of the libraries built with the project, following the libtool convention
https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
of having specific versions for the libraries that basically just count the number of ABI changes and how many generations of the library are backwards compatible, with CURRENT.REVISION.AGE instead of MAJOR.MINOR.PATCH. In practice, this means that the library stays at version 0 for a long time, just gets revision increases, reminding of the epic shift from libc.so.5 to libc.so.6 for glibc (been some time now;-). You might automate the library revision number, calculating from the main release version.
So … you could start with libscalapack.so.2.2.0, with 2.2.1 release then with 2.2.2 release libscalapack.so.2.3.0. On release 2.3.0, if it doesn't break ABI, just adds things, it would be libscalapack.so.2.4.0. The actual SONAME would be libscalapack.so.2 for all of those. The jump to libscalapack.so.3 should happen if ABI compatibility has to be broken.