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

[Achim Bohnet]

On Sunday, 4. March 2007, Andreas Huggel wrote:
> 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 numbr 
> 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 

General note the important point is for a library backward
compatibility of the ABI.  Changes in the API/ABI, e.g, adding
functions, methods is okay.

The release number of a library and API version are two different
this. In early days of a library every now version can break ABI
backward compatibility, nevertheless the two name different things.
A simple change can break the backward compatibility while
tons of additions e.g. more/better may not touch the API at all.



> versioning system is only meaningful if API/ABI are reasonably stable. 
> Exiv2 will get there too.

Side note:

If there a good reason to break the backward compatiblity, good.
we have the source we can adapt fix things.  Nevertheless ... ;)

For distributions an API/ABI change usually mean, that they
have to adapt and rebuild, adapting dependencies of
all applications that (indirectly) use this library.
Especially with dynamicly loaded plugins (e.g. kipi-plugins)
preventing that two incompatible version of a libary do not get
loaded is hardly trackable automaticly :(

So it takes time pickup a new libray interface and integrate it
into a distribution.   And may therefore delay the inclusion of
an application, when a distro is in the conservative period
before an release.

Don't get me wrong:  I'm really glad that exiv2 provides a library
interface, making it easier for lots of other applications to
make use of it's feature!!!!!!!!!!!!!!!!!

Summary: the more often you can delay or workaround an back-
wardcompatibilty breaking change, the faster, we the distro-
packager, can deliver your great peace of software to our
users.

> For an example of a subtle API change see 
> http://uk.groups.yahoo.com/group/exiv2/message/523

After a quick look, I'm sure I miss something ;)
About the the parsing of a string by digikam, the breakage due to
this subtle change, was either digikam fault (using API the wrong way),
or a limitatin in the library interface (providing a onely human
readable string, instead of an alternative with computer readable
values ;)   And e.g. adding methods that return directly usable
values without parsing would not break the ABI backward compatibility.

So if this was the only suble change ABI change, it would have
benn easier adding some methods and/or fix digikam using the lib
'properly' and keeping the backward compatibility of the lib.

Last but not least: thx again for you exiv2 work!!!
Achim

> 
> Andreas
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
> 
> 



-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- reddy at lion.austin.ibm.com