Currently cantor uses KDE_APPLICATIONS_VERSION_MAJOR as SOVERSION for libcantorlibs. This is totally wrong: the SOVERSION is meant to indicate the ABI version and not to be arbitrarily increased once a year. This forces a rebuild of applications that link to it (eg. labplot) once a year even if there are no ABI changes. Please set SOVERSION to a fixed number that is only increased when there are backwards incompatible ABI changes.
I am not very familiar with ABI version management, what you could suggest?
The number itself is not really important, as long as it is bumped when (and only when) there is a new release which breaks existing API/ABI. Since it's currently at 18, I'd suggest to set it to 18 for the current API
I mean, there are tool for checking, that ABI was changed, because I don't thinkg, that handling the version by hands will be very successfull (i think, this is reason, why SOVERSION just setted by major version)
(In reply to Antonio Rojas from comment #0) > Currently cantor uses KDE_APPLICATIONS_VERSION_MAJOR as SOVERSION for > libcantorlibs. This is totally wrong: the SOVERSION is meant to indicate the > ABI version and not to be arbitrarily increased once a year. This forces a > rebuild of applications that link to it (eg. labplot) once a year even if > there are no ABI changes. > > Please set SOVERSION to a fixed number that is only increased when there are > backwards incompatible ABI changes. Here on openSuse labplot is linked against /usr/lib64/libcantorlibs.so.18 which is a symlink to libcantorlibs.so.18.07.70. SOVERSION being set to KDE_APPLICATIONS_VERSION_MAJOR makes cmake to create that symlink. Whith this it is meant that Cantor guarantees the stability of ABI for one major release (for one year). This is basically the same what you suggest by setting this version manually to 18. Why do you get the problem with linking?
(In reply to Alexander Semke from comment #4) > (In reply to Antonio Rojas from comment #0) > > Currently cantor uses KDE_APPLICATIONS_VERSION_MAJOR as SOVERSION for > > libcantorlibs. This is totally wrong: the SOVERSION is meant to indicate the > > ABI version and not to be arbitrarily increased once a year. This forces a > > rebuild of applications that link to it (eg. labplot) once a year even if > > there are no ABI changes. > > > > Please set SOVERSION to a fixed number that is only increased when there are > > backwards incompatible ABI changes. > > Here on openSuse labplot is linked against /usr/lib64/libcantorlibs.so.18 > which is a symlink to libcantorlibs.so.18.07.70. SOVERSION being set to > KDE_APPLICATIONS_VERSION_MAJOR makes cmake to create that symlink. Whith > this it is meant that Cantor guarantees the stability of ABI for one major > release (for one year). This is basically the same what you suggest by > setting this version manually to 18. Why do you get the problem with linking? A major release in KDE Applications is every 4 months, not every year. So, unless you guarantee that you only plan to make ABI breaking changes in the xx.04 cycles and not in the xx.08 or the xx.12 ones, this system doesn't make much sense
(In reply to Antonio Rojas from comment #5) > A major release in KDE Applications is every 4 months, not every year. So, > unless you guarantee that you only plan to make ABI breaking changes in the > xx.04 cycles and not in the xx.08 or the xx.12 ones, this system doesn't > make much sense Yes, but the leading/major number stays constant for all releases within one year - 18.04, 18.08 and 18.12. So, as long as you link against libcantorlibs.so.18, or even libcantorlibs.so, everything should be fine, shouldn't it?
(In reply to Alexander Semke from comment #6) > (In reply to Antonio Rojas from comment #5) > > A major release in KDE Applications is every 4 months, not every year. So, > > unless you guarantee that you only plan to make ABI breaking changes in the > > xx.04 cycles and not in the xx.08 or the xx.12 ones, this system doesn't > > make much sense > Yes, but the leading/major number stays constant for all releases within one > year - 18.04, 18.08 and 18.12. So, as long as you link against > libcantorlibs.so.18, or even libcantorlibs.so, everything should be fine, > shouldn't it? No, it isn't. If you commit an ABI-breaking change in June to master, it will end up in the 18.08 release. This release will have a different ABI than 18.04 even though it has the same soversion, packagers won't notice that they need to rebuild stuff that links to it, leading to breakage. The only way the current schema makes sense is if you only allow breaking ABI between December and April, which seems to me a rather peculiar workflow
(In reply to Antonio Rojas from comment #7) > (In reply to Alexander Semke from comment #6) > > (In reply to Antonio Rojas from comment #5) > > > A major release in KDE Applications is every 4 months, not every year. So, > > > unless you guarantee that you only plan to make ABI breaking changes in the > > > xx.04 cycles and not in the xx.08 or the xx.12 ones, this system doesn't > > > make much sense > > Yes, but the leading/major number stays constant for all releases within one > > year - 18.04, 18.08 and 18.12. So, as long as you link against > > libcantorlibs.so.18, or even libcantorlibs.so, everything should be fine, > > shouldn't it? > > No, it isn't. If you commit an ABI-breaking change in June to master, it > will end up in the 18.08 release. This release will have a different ABI > than 18.04 even though it has the same soversion, packagers won't notice > that they need to rebuild stuff that links to it, leading to breakage. > The only way the current schema makes sense is if you only allow breaking > ABI between December and April, which seems to me a rather peculiar workflow Ok. I got your point. Let us check how this is done in other KDE frameworks and adjust accordingly. As the author of LabPlot I'd rather like to combine both projects to get more tigher integration and to also avoid this kind of problems with the stability of the ABI...
Frameworks is not really a good example since they have a stable ABI. See okular or ktp-common-internals for other KDE Applications projects that do this properly.
(In reply to Antonio Rojas from comment #9) > Frameworks is not really a good example since they have a stable ABI. See > okular or ktp-common-internals for other KDE Applications projects that do > this properly. Ok. Thanks for the pointer.
Git commit 006013ba3416b2e0dd63926e270a932f7ce4f793 by Nikita Sirgienko. Committed on 19/08/2018 at 18:27. Pushed by sirgienko into branch 'master'. Set SOVERSION cantorlib as 18. Increase before release, if ABI changes (we can use abi-compliance-checker for checking this) FIXED-IN:18.08.1 M +1 -1 src/lib/CMakeLists.txt https://commits.kde.org/cantor/006013ba3416b2e0dd63926e270a932f7ce4f793
This was committed to 'master' -> 18.12