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

[Aaron J. Seigo]

On Friday 24 April 2009, Modestas Vainius wrote:
> Hello,
>
> On 2009 m. April 23 d., Thursday 23:50:46 Aaron J. Seigo wrote:
> > svn location: extragear/libs/knotificationitem
> > headers: $INCLUDE_PATH/knotificationaitem-1/
> > lib name: $LIB_PATH/libknotificationitem-1.so
> > namespace: Experimental::
> >
> > release of tarball done prior to kde 4.3.
> >
> > will most likely be removed post-4.3 and rolled into kdelibs. if not,
> > changes will results in a s,-1,-2,g to the above and another release.
> >
> > objections?
>
> Why do you insist on creating shared libraries?

because it's simple, easy and i don't have to recompile all N apps just to 
test changes properly.

think about the system tray here: we've ported half a dozen or so apps 
scattered all over kde's svn. when i make a change in the lib, right now i 
just restart those apps.

with the static lib mentality, i now have to go and relink each app first.

just as bad, when introducing changes in the lib, person A may get different 
behavior from person B even if they both have the same svn rev just because 
one or the other didn't relink that app.

a shared lib is simpler and more respecting of my time as a developer.

> If ABI is unstable, create
> static libraries instead (or at least make it an option). Static libraries
> will ensure that:
>
> 1) use of the library is not widespread. It is experimental after all.

static libs guarantee no such thing.

> 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.

> (your goal should be
> to develop a stable API/ABI, not to keep library experimental forever).

correct

> 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.

-- 
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/20090424/f1c1c41a/attachment.sig>