RFC: adding a temporary, non-BC gauranteed, 'private' library .. where?
Aaron J. Seigo
aseigo at kde.org
Thu Apr 23 19:13:21 BST 2009
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.
> 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...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel