KDE ABI stability?

[Christian Loose]

On Sunday 04 December 2005 18:47, Kevin Krammer wrote:
> On Sunday 04 December 2005 18:36, Thiago Macieira wrote:
> > Kevin Krammer wrote:
> > >> This means a program that compiled and ran with KDE 3.0.0 must still
> > >> compile and run with 3.5.0 (including running without re-compiling).
> > >
> > >Unfortunately this seems only be true for kdelibs. I remember a thread
> > > on debian-qt-kde (Debian KDE packagers list) about one of the other
> > > modules breaking BC in a library shared with another module.
> >
> > All *public* libraries are supposed to maintain BC. Non-public ones and
> > non-library code doesn't have to maintain.
>
> Sounds reasonable.
>
> > I am not sure whether libcvsservice was supposed to be public or not, but
> > it does have public headers. This looks like a bug from the cervisia
> > developers.
>
> Unfortunately nobody seemed to know about it. Both me and Ian Geiser
> (thread starter IIRC) insisted on the very thread that KDE was supposed to
> be binary stable within a major release but we were told that this wasn't
> the case.
>
> Even more unfortunately this had a bad impact on KDE's credability, i.e.
> "our" Debian packagers stay on the safe side and force removal of
> applications linking to an older KDE version than the one being installed.
>
> E.g. removing all 3.4 apps when 3.5 is installed as part of an upgrade,
> which results in all KDE .org applications to be updated as well (not so
> bad) but all third party packaged applications removed (not very nice)
>
>

Since I was the cause for the libcvsservice mess, my POV might be interesting 
here.

1. What is libcvsservice?

libcvsservice is a small library that just contains DCOPStub classes for the 
cvs DCOP service (kdesdk/cervisia/cvsservice). I created it to make it easier 
for 3rd party developers (Quanta, KDevelop, etc) to use the service.

Looking back, this was a bad idea and I will remove it for KDE4.

2. What happened? What was the BIC change?

For a new feature, I needed to add parameters to an existing method in the 
DCOP interface. In order to ensure compatibility for existing users of the 
service (how ironic), I added copies of those methods with the new 
parameters.

What I didn't know (and didn't check) was that the dcopidl2cpp tool declares 
all methods of the DCOP interface as virtual in the generated DCOPStub (see 
http://websvn.kde.org/branches/KDE/3.5/kdelibs/dcop/dcopidl2cpp/stub.cpp).
IMHO needlessly (and the author seems not to sure about it either) but this 
was the BIC change.

> Assuming that the bug was indeed a BIC change in libcvsservice, it could
> indicate that non-core developers are not aware of the binary compatability
> requirement or uncertain when a library has to be considered public.

I'm little confused why I was never contacted by the debian packagers.  I only 
know about this problem because  Andras Mantia wrote me a mail about it. We 
back then solved it for Quanta by not using the library at all.

I do know about KDEs BC requirements and that libcvsservice is a public 
library, but I didn't check the generated code of dcopidl2cpp. That was my 
big mistake.

Bye, Christian