RFC v2: adding a temporary, non-BC gauranteed, 'private' library

[Modestas Vainius]

Hello,

On 2009 m. April 24 d., Friday 20:08:48 Aaron J. Seigo wrote:
> static libs guarantee no such thing.
Not directly, but they are more PITA to deal with hence less attractive. If 
somebody starts using "experimental" library excessively, something is wrong 
with it being "experimental".

> > 2) developers do not have to deal with sonames, abi and other versioning
> > nonsense when there is no intention to keep ABI stable
>
> cmake deals with it for us; it's not a big deal. it's one more word in the
> target_link_libraries entry.
cmake might deal with it, but what about the respective find_package().

> > 3)
> > it's bad from security support POV, but if 1) is met, it may be more
> > acceptable than suffering from constant ABI brekages.
>
> if the API is going through constant ABI breakage, then it isn't ready for
> this process. only when an API is ready for trialing for actual inclusion
> in, say, kdelibs would you put it in there. that means a fairly confident
> API, but not confident enough to commit to 5+ years of support.
So you have to set a few rules here, because I might understand "constant 
breakage" differently than you. libplasma ABI breakages used to be very 
constant from my POV. May I remind you that you want to _release_ stable KDE 
depending on this library. So will you let yourself to break API/ABI for minor 
KDE stable release?

-- 
Modestas Vainius <modestas at vainius.eu>
-------------- 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/20090424/df2232d6/attachment.sig>