[Digikam-devel] Fwd: Trans.: [exiv2] Exiv2 release 0.13

[Gilles Caulier]

Nota : Andreas, to improve the binary compatibilty, we can use a d private
internal class everywhere to contain all private members.

Like this, if you add a new private member in a class the benary is not
broken because private member declarations are include in cpp files not in
hpp.

This way increase the compilation time too... When the API will be more
stable for you, i can patch the library like this. I know very well this
technic since i have patched all digiKam core implementation.
Also, libkexiv2 and libkdcraw are implemented using d private class.

Friendly

Gilles


2007/3/4, Angelo Naselli <anaselli at linux.it>:
>
> Alle 12:32, domenica 4 marzo 2007, Andreas Huggel ha scritto:
> > On Sunday 04 March 2007 15:14, Gilles Caulier wrote:
> > > Angelo, Achim,
> > >
> > > The Exiv2 library coordinator is in this room (Andreas).
> > >
> > > Andreas, what do you think about versionning number?
> > >
> > > Gilles
> >
> > Exiv2 and it's interface are still unstable. Thus the 0.x version number
> > and the use of the simple library versioning mechanism. The API/ABI
> > change with every version, although sometimes in subtle ways (which is
> > worse); the current versioning system makes this very clear. The other
> > versioning system is only meaningful if API/ABI are reasonably stable.
> > Exiv2 will get there too.
> >
> > For an example of a subtle API change see
> > http://uk.groups.yahoo.com/group/exiv2/message/523
> I don't fully agree with that, if a bug fixing change the api, or an
> api changes you can always break binary compatibility using  -version-info
> just increasing the first number and let others (two) to zero.
> The right now versioning system is by default a compatibility breaker.
> And you can never say from now on i won't break it because you change
> the name of the library and who use the old one cannot use the new one
> without rebuilding itself.
> You can always break binary compatibility using also  -release X.Y
> IMO libtools is quite clear.
>
> Angelo
>
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20070304/5509bb73/attachment.html>