RFC v2: adding a temporary, non-BC gauranteed, 'private' library

Andreas Pakulat apaku at gmx.de
Fri Apr 24 22:28:07 BST 2009

On 25.04.09 00:01:42, Modestas Vainius wrote:
> On 2009 m. April 24 d., Friday 23:31:40 Aaron J. Seigo wrote:
> > > libplasma ABI breakages used to be very
> > > constant from my POV.
> >
> > which is why we kept it in kdebase until it (and QGraphicsView, which was
> > one of the major motivations for BC changes) was mature.
> Yes, but libplasma had only 2 SONAME bumps whereas there were a lot more 
> ABI/API breakages. That's why I'm saying that shared linkage for unstable 
> API/ABI is a nightmare to manage.

But there were only two releases of libplasma. What libplasma does in
trunk/ doesn't play any role here, it may happily break API/ABI every
day (same for any other lib outside of the core libs), as long as for
the _release_ the soname is increased (or rather at the first breakage
its increased).
> > > So will you let yourself to break API/ABI for minor KDE stable release?
> >
> > it really depends on the library, and if it breaks between releases then it
> > _should_ have the .so number changed.
> Do you really expect to change SONAME of that lib between minor KDE releases? 

Assuming minor means between 4.3 and 4.4, thats exactly what Aaron is

> Btw, packagers release packages of KDE development releases these days and 
> those non-SONAME ABI breakages are not fun.

And its really cool that you do, however packaging systems have ways to
enforce that a beta2 package of a library de-installs all apps that were
linked against beta1 (unless a newer version linked against beta2 is
available). And thats exactly what the packages for beta versions and
rc's should do (not to mention packages created from development
snapshots). I personally don't want to spend my time finding out wether
adding a member function to a class is BiC such that I have to change


You are fighting for survival in your own sweet and gentle way.

More information about the kde-core-devel mailing list