Bumping SOVERSION

[Sandro Knauß]

Hey,

> > nope. We do not release every month We release a new major version every 4
> > months! But what you have against a so.15? There is nothing why you should
> > be afraid of an so.15. see answers to dan for more details.
> 
> While this might be mostly cosmetic in some cases, this is at least a
> problem for things using the KF5 library namespace already, we'd be out of
> sync with KF5 (so)versioning for stuff supposed to move there eventually.

It is only a cosmetic issue for KF5 library namespace, too. There is only the 
rule, that the ABI needs to keep stable within Frameworks and yes most 
frameworks started with SONAME 5 and kept there ABI stability. But we have 
f.ex.
libkf5bluezqt SONAME 6
libkf5activitiesstats SONAME 1

So the SONAME won't be a blocker for going into Frameworks. 

> That btw is the real solution to this IMHO, getting ABI guarantees back to
> what used to be kdepimlibs.

ACK

> > > #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 ?
> > 
> > Nope, we ship the same ABI but Qt internally makes sure, that you are only
> > able to build with the same Qt version.
> 
> Not sure I understand your answer here:
> - Qt is updated from 5.11 to 5.12, ABI compatible, it's SOVERSION stays "5",
> therefore no rebuild of packages depending on it
> - kpimtextedit gets rebuild due to a minor bugfix, not changing its ABI, no
> SOVERSION bump. However now the #ifdef kicks in now and changes the ABI.
> - packages depending on kpimtextedit don't notice the ABI change and are not
> rebuilt -> boom

Nope it would go that way:
- Qt is updated from 5.11 to 5.12, ABI compatible, it's SOVERSION stays "5", 
therefore no rebuild of packages depending on it
- kpimtextedit gets rebuild due to a minor bugfix - However now the #ifdef 
kicks in now and changes the ABI. Debian has own symbols tracking, so the 
built fails because of symbol changed. That means the maintainer would change 
the package name for the library, update symbols and triggers a rebuilt of 
everything depending on kpimtextedit.

This is a case where it is totally fine that distributions handle this, because 
those are distribution internal changes. And good example why distributions 
need symbol tracking.
We had the case when gcc 5 came out most symbols changed, so Debian needed to 
rebuilt everything this was also tackled down by renaming the package and 
updating the symbols files.

>From a upstream point of view (aka kdepim) we can't do anything about symbol 
changes because of gcc changes nor we can't do anything for Qt5.11 -> Qt5.12. 
What I want to say is, that updates of libraries we depending on, can always 
trigger symbol changes, so there is nothing special about this #ifdef.

hefee