Bumping SOVERSION

[laurent Montel]

Le vendredi 15 mars 2019, 18:00:23 CET Daniel Vrátil a écrit :
> On Friday, March 15, 2019 4:20:11 PM CET Sandro Knauß wrote:
> > Hey,
> 
> Hi Sandro,

Hi,

> > we already had some discussions about bumping the SOVERSION and the
> > discussion ended with something like, that I should evaluate a solution
> > and
> > come up with a suggestion[0]. I implemented a abi-checker on our CI, so we
> > can now answer the question when we break the ABI and need to bump the
> > SOVERSION. And the CI tells me that less than 50% of our libraries need to
> > be bumped base 18.12.0. You can check yourself:
> > https://build.kde.org/job/Applications/job/messagelib/job/kf5-qt5%20SUSEQt
> > 5. 10/lastSuccessfulBuild/artifact/compat_reports/
> > KF5MessageViewer_compat_report.html
> > 
> > I started to bump the SOVERSIONS yesterday but Laurent reverted my changes
> > [1]. Laurent please instead of silently revert commits inform the author
> > of
> > the commit and start a discussion here. I'm not a random dev than drive by
> > and breaks stuff.
> 
> I'll side with Laurent on this - I believe in this case it is you who should
> have announced it on the list for discussion first before starting to
> implement this kind of change, not after someone reverted your commits. I
> personally already forgot about this discussion, so to me this change came
> out of the blue, same for Laurent, I'm sure.

Sorry but a discussion that we did in 2016... We are in 2019 and for sure I 
forgot this discussion.

The freeze is today and you just started to do it yesterday without speaking 
about it.


> 
> > Bumping the SOVERSION, if we break ABI is quite important for all Linux
> > distros, as they can need to handle the case, that kdepim broke it ABI and
> > rebuild everything against the new ABI. And please keep in mind we also
> > have users outside kdepim that are using kdepim libs that don't have the
> > same release schedule (zanshin, digikam,...). Why bumping helps? I can
> > check this app is linked against the old version aka I need to recompile.
> Just to refresh my memory, is it because only the major soversion (5) is
> taken in account by distributions and considered relevant, e.g. 5.10.0 and
> 5.11.0 are seen as having the same ABI? Considering how often and unevenly
> we break ABI in our libraries the numbers would get pretty crazy pretty
> quickly.

ABI in kdepim is not stable, we decided it when we switched to kf5.

We break each month for some lib.
I don't want to have a .so.15 in 1 years...

After I don't understand why it's necessary to do it as when we update kdepim 
we have a dependancies against all pim package.
Increase ABI version for pimcommon ?? which package uses it outside pim ?

And how do you manage a code as:

#if QT_VERSION > 5.12
void foo (QRegularExpression )
#else
void foo (QRegExp )
#endif

?
We have it in kpimtextedit.
So you want that we increase ABI depend against Qt version ?


> As a random idea, what about encoding the full version into a single number
> (5.10.2 -> 51002) and use that for soversion? This way new version would
> automatically get a new soversion and the numbers would still remain sane
> and consistent.
> 
> > I got a lot of bugreports and workarounds in Debian because of not bumped
> > libs and issues, because the builders take some hours to build kdepim for
> > every supported arch so parts of kdepim got available before others and
> > this triggered core dumps, because of missing symbols etc. For Debian I
> > workaround this by patching the packages to ship a SOVERSION 5abi1 or
> > 5abi2.
> > 
> > Care about the SOVERSION is really nothing about giving any ABI stability
> > guarantees. Giving ABI stability guarantees would mean, that we don't need
> > to bump the SOVERSION.
> > 
> > It is simple bookkeeping, to make sue users of our libs get the
> > information, that they need to recompile.
> > 
> > As we now the first freeze (dependency frezze happend) it would be great
> > to
> > come to conclusion in the next days.
> 
> Maybe it is too late to implement this at this point before freeze. Since
> you now have something to report, maybe it would make sense to wait with
> this discussion for the Toulouse sprint in couple weeks, we can decide if
> and how to implement this for 19.08?

For me we can't change it now as it's the freeze today.


> 
> Regards,
> Dan
> 
> > sandro
> > 
> > [0] https://community.kde.org/KDE_PIM/Meetings/
> > Toulouse2016#Bumping_so_version_number
> > [1]
> > https://commits.kde.org/pimcommon/e5b225022a651568ce49d14efa7c5da3acbd7012


-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer 
KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 
 www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent 
software solutions