Closed gijzelaerr closed 4 years ago
@olebole how do you recommend we deal with this? Is it not done to add the minor version also to the library version in the debian package name to avoid this kind of issues in the future?
For library packages, it is useful to adopt the semantic versioning, so that a every casacore package that changes the ABI gets a new major version number. An alternative for shared libs is to just handle the soversion independently of the software version and to increase it whenever the ABI changes. F.e. the "cpl" libraries from ESO follow this scheme: the software version number is currently 7.1.2, while the soversion is 26. Semantic versioning is however the standard approach.
What is a bit bad about frequent ABI changes is that one needs to recompile all dependent programs on every soversion change. Since casacore is the base of quite a number of packages, I would rather recommend to keep the ABI stable for some time and not to change it on every new release. So, best of this all would be if soversion would be handled upstream. If they don't, I would just use an increasing number (as ESO does).
@tammojan maybe good to get you involved also.
casacore does semantic versioning, but ABI changes have happened and probably keep on happening for minor versions.
I guess there is no option left now to just increment the debian lib version to 4.
If there are ABI changes on minor versions, then casacore just does not use semver (because the increase of the major number for ABI changes is the basic idea of semantic versioning).
We can get technical here, but the API didn't change in a backwards-incompatible way, the ABI did. The semver website doesn't mention ABIs.
Anyway, if it was up to me casacore would do this better but the current state is that it didn't.
3.2.1 has been uploaded to KERN-dev
there are ABI differences between casacore 3.0 and 3.1. Current Debian SO version is set to 3. Incrementing this to 4 should probably happen, but this might confuse people. How to deal with this?