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

[Aaron J. Seigo]

On Thursday 23 April 2009, Thiago Macieira wrote:
> Thiago Macieira wrote:
> >2) don't ever remove it
> >
> >And in either case, you have to put the headers in the same place as
> > kdeui (i.e., future compatibility)

there is no intention for future compatibility; what we're hoping to do is 
provide a new, shared bit of code between some of the KDE project's apps as a 
way to safely trial them in a release without pushing them into kdelibs proper 
and all the BC and API guarantees that requires.

i'd like something between "not released" and "we're committed to it exactly 
as-is for the next N years".

> > and you have to use a hidden
> > namespace to avoid conflicting with the symbols when it does make its
> > way to kdeui (à la Animations Solution).

namespacing is easy enough, yes.

> Hmm... you can't move symbols from one library to another (see
> src/corelib/xml/qxmlstream.h for information in our attempt). If you
> change the symbol name, be it by changing the namespace or removing it,
> then the changes are source-compatible but not binary.

we're not expecting binary compatibility.

> It only works as long as those classes are never used in ANY public API.

they aren't.

> And like QXmlStreamXXXX classes today, you can't forward-declare them.

even in application code?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- 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/20090423/5bde8ff4/attachment.sig>