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

[Alexander Neundorf]

On Friday 24 April 2009, Aaron J. Seigo wrote:
> 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.

Would it be an option to make it optional whether the lib is built shared or 
static, making static the default and for releases, and you as a developer 
could switch it to shared so you get the advantages you mention ?

Alex