RFC: adding a temporary, non-BC gauranteed, 'private' library .. where?

Friedrich W. H. Kossebau kossebau at kde.org
Thu Apr 23 22:24:20 BST 2009

Jeudi, le 23 avril 2009, à 23:01, Alexander Neundorf a écrit:
> On Thursday 23 April 2009, Friedrich W. H. Kossebau wrote:
> > Hi Aaron and all,
> ...
> > So if there e.g. can be another module for libraries, in the dependency
> > chain between the base lib modules (kdelibs and kdepimlibs) and the base
> > modules (kdebase, kdeutils, kde...) and not bound to ABI stability
> > between major releases, that would be helpful. To give new libraries a
> > chance to develop.
> Maybe new libs could be for the first release cycle in kdelibs-experimental
> and if they prove to be good advance to kdelibs for the next cycle,
> otherwise be removed again ?

Not precisely what I thought of. Take the Okteta libs. They will change for 
4.3. They will change for 4.4 again. And they might change for 4.5 again. 
Because they are in development and getting feedback by more use cases. These 
use cases will increase if other programs will depend on it, once the libs 
are published. But being part of kdeutils (which also has to fulfill the ABI 
needs) I cannot install the headers, so 3rd party developers would have to 
copy the whole sources, which is kind of a hurdle. I guess this fate is 
shared with quite some libs, like Aaron's libknotificationitem.

> > And if adding this module or another similar option, on this change also
> > kdebase should be finally split up as well, by lifting the three hidden
> > modules on the level where they belong.
> You mean a kdebaselibs module ?

Yesno, I mean some kderuntime, kdeworkspace and kdebase (with only the base 
apps left) modules.

Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta

More information about the kde-core-devel mailing list