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

[Friedrich W. H. Kossebau]

Hi Aaron and all,

Mercredi, le 22 avril 2009, à 22:21, Aaron J. Seigo a écrit:
> hi all ..
>
> i'd like to move libknotificationareaitem somewhere that apps can get to it
> for 4.3, before looking at moving the actual class into libkdeui for 4.4.
>
> is there any guidance on where it could go, how it should be installed,
> etc? right now i'm thinking of putting the headers in knotificationarea/,
> but half of me wonders if a generic private/ or experimental/ include dir
> wouldn't be a bad idea ...
>
> any thoughts?

A general solution to this problem would be very welcome also by me.

With Okteta I have a similar problem, in that the core libraries are 
interesting to developers of other programs but not stable enough to have a 
guaranteed API until the rest of KDE 4 lifetime.

When I asked for that problem on the release-team list it was proposed to me 
to put the libs to extragear so they are not bound to the promises made for 
the ABI of the general KDE modules. I haven't yet followed that proposal for 
these reasons:
* some extra work for me
* people running trunk might not fetch also the stuff from _extra_gear, so 
Okteta would not be built which would mean less testers.

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.

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.

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