-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adopt a conservative ABI / SOVERSION policy #68
Comments
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;-) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#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.
The text was updated successfully, but these errors were encountered: