KDE ABI stability?

[Nicolas Goutte]

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.

To avoid a possible misunderstanding: an application built from an older 
version of KDE should work on a  younger version (assuming the same major 
version) but not the other way round.

Also that works as long as Qt keeps its binary compatibility, which was not 
entirely the case during (early) Qt3 (for example plugins).

Also binary compatibility is not enough. KDE should have a 
behaviour-compatibility rule, which it does not have. (Example: two changes 
of the handling for "recent files", each breaking KDE applications.)

>
(...)

> 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 think that the problem is that the BC rules are not easy to understand, as 
you enter the subtle realms of C++. For examples, the multiple inlined 
constructors in public kdelibs classes that disallow to use of the planned 
private class defined by the corresponding public class.

Also it is perhaps easy to forget that an application has a public API too. 
(It seems that I have managed to break KBabel's one for KDE 3.5.)

>
> Cheers,
> Kevin

Have a nice day!