Nepomuk + kdelibs + BC

Sebastian Trüg strueg at
Fri Jan 11 07:50:50 GMT 2008

On Friday 11 January 2008 00:54:21 Michael Pyne wrote:
> On Thursday 10 January 2008, Allen Winter wrote:
> > On Thursday 10 January 2008 04:07:44 Sebastian Trüg wrote:
> > > Hi guys,
> > >
> > > is it ok for me to do a little binary comp breakage in kdelibs/nepomuk
> > > for KDE 4.1. I want to change the API of some classes (which are so far
> > > only used by me AFAIK) to match the general QT/KDE design, make them
> > > faster and cleaner.
> > >
> > > Any objections for me to do that?
> >
> > Could you post a patch?
> >
> > How about  creating new methods and deprecating the old?
> I don't like the idea of breaking BC.  But since Nepomuk is it's own .so
> it's at least something that packagers can work around by having a
> libnepomuk-40 type package for KDE 4.0 applications.
> How does changing all the return types affect source compatibility though?
> Can a one-off application written against 4.0.2 compile against 4.1?

I thought about it and I can keep Nepomuk::Resource BC by simply introducing 
new constructors and marking the old deprecated. I will then leave the return 
types as is. It is not as pretty but not that big a deal.

As for the other patch, Nepomuk::Class and Nepouk::Property: I could move the 
new classes to some new namespace like Nepomuk::Types and then make the old 
classes just deprecated wrappers around the new ones, thus staying BC, too.

How about that?
I know it is problematic but I did not think of this improvement before. it 
just came to me last week. :( And it really makes a difference in performance 
and handling.


More information about the kde-core-devel mailing list