Using the KomparePart in KDevelop

[Kevin Kofler]

On Thursday 23 July 2009, Andreas Pakulat wrote:
> Not the part, but indeed the library needs it - unless the maintainers
> don't enforce BC during the KDE4 lifetime?

So far, the internal Kompare libraries have been in ABI Wild West, I even 
backported ABI changes (which were part of bugfixes) to 4.2.x point releases 
(with no soname bump). But if something outside of Kompare starts actually 
using those libraries, that will have to change. :-(

I'd be pragmatic and say: as long as KDevelop is the only external user of 
those libraries, feel free to do the changes you need on your schedule as long 
as you update the main Kompare application at the same time (so it keeps 
working). You do need to bump the soname if you change the ABI of a public 
library, and there are also policies on not doing such bumps in a point 
release (e.g. you can bump the ABI of a library in an application module like 
kdesdk for KDE 4.n->4.n+1, but you're normally not supposed to do that for KDE 
4.m.n->4.m.n+1 and you may get into trouble with the KDE Release Team if you 
try doing that; that said, distros like Fedora which plan to ship KDevelop 4 
as soon as possible may be backporting those required API/ABI changes, we 
already did that to kdegraphics in KDE 4.1.x for Digikam 0.10 Beta, and in 
this case Fedora would automatically have upstream buyin to do those backports 
because I happen to be Kompare's upstream maintainer ;-) ). Of course, the 
more users the library gets, the more ABI compatibility gets important. (But 
binary compatibility is not required for the entire lifetime of KDE 4 as it is 
for kdelibs and kdepimlibs.)

Note that KParts do also have an ABI, but the encapsulation there is stronger 
than for a regular library: not everything that's public in the class 
implementing the KPart is actually accessible from the outside, see e.g. how 
the KatePart selectively exports APIs.

        Kevin Kofler