Bumping SOVERSION

[Sandro Knauß]

Hey,

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

Yeah sorry for that - I just thought that everyone has this still in mind. Yes 
I know I should have asked, but I also wanted to fix that long outstanding 
issue for pim in terms of releasing...

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

ABI Versions SOVERSION has nothing to do with the version of the produkt and 
SOVERSION doesn't needs to be a single number it can be anything. But most 
tooling use a single number or together with the mayor number aka 5.10. I 
don't understand why you are afraid of high numbers. There is no special 
meaning inside the SOVERSION. Just an example KDevPlatform has a SOVERSION of 
54 and so what?

>Considering how often and unevenly we break ABI in our libraries the numbers 
would get pretty crazy pretty quickly. 

We need to bump the SOVERSION once if we broke it against a released version. 
That means not faster than the major version of our product aka 5.11 may would 
hve result in a SOVERSION 15 if it would got broken in every release cycle. 
Because we only need to bump it ONCE before we release the new version. Not 
while we do development in master. 

Why I don't like this automatic version -> SOVERSION approach: We force 
Distributions to rebuild everything with every release, also if it is not 
needed. Also if we control it by hand, we have a better overview, how stable 
the libraries are and may consider a library to be ready for Frameworks. And 
users of the pim libraries Zanshin etc. can spot it more easily when they need 
to rebuild. And I volunteer to do this work. Also Framewokrs don't have 
SOVERSION 5 everywhere, so having a SOVERSION different of 5 is not a 
showstopper for the move to Frameworks.

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

Well we only accept bugfixes in minor updates so 5.10.X should be have one ABI 
and I think we never broke the ABI within one release cycle.

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

Well we have time until the rc will be released. As I don't attend Toulouse 
sprint this year, we need to do it online anyways. 

regards,

sandro

-------------- 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/ecc9893a/attachment.sig>