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