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

[Kevin Ottens]

On Thursday 23 April 2009 22:17:35 Aaron J. Seigo wrote:
> On Thursday 23 April 2009, Aaron J. Seigo wrote:
> > On Thursday 23 April 2009, Sune Vuorela wrote:
> > > > We're guaranteeing that for the public libraries of kdelibs, not for
> > > > anything thats considered private.
> > >
> > > Once you install the headers, it is a public library.
> >
> > so phonon's experimental lib is a problem too? because as i understand
> > it, it's doing the same thing. how do you handle that in packaging?
>
> nmind; it was pointed out to me that this is all (at least in theory?)
> private to libphonon itself. though i'm mildly curious about that as the
> headers are actually installed and marked with exports.

Not sure who told you that. But it's definitely surprising... Just look at the 
content of libphononexperimental and it's clear that it's not only for 
libphonon internals. For instance, visualization and audio/video capture bits 
are clearly extra features for apps not provided by libphonon.

Of course it's not widely used because of the scary "experimental" label. And 
honestly I think we should do the same for your proposed classes using a 
libkdeuiexperimental. It's a good way to do staging with our libraries. It has 
to be clear that the stuff in there will be temporary though, but that's 
exactly what you had in mind.

Regards.

PS: And sorry for jumping in the discussion so late. Just noticed it this 
morning. ;-)
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090505/1ff2de0f/attachment.sig>