Bumping SOVERSION

[Daniel Vrátil]

On Friday, March 15, 2019 4:20:11 PM CET Sandro Knauß wrote:
> Hey,

Hi Sandro,

> 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%20SUSEQt5.
> 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.

> 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.

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?

Regards,
Dan

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


-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20190315/3c09ad7b/attachment.sig>