[ghemical-devel] Ghemical-2.95 is now released

[Daniel Macks]

On Mon, Oct 08, 2007 at 12:05:37AM +0200, Michael Banck wrote:
> On Mon, Sep 24, 2007 at 12:27:26PM +0300, Tommi Hassinen wrote:
> > So, to summarize, there is not much new, but the old stuff is packed in a 
> > more neat and clever way, so that it can be handled more easily in the 
> > future.
> 
> Now that I started packaging the bunch of releases for Debian, I am not
> very happy about the library version breakage (i.e. the library changed
> e.g. from libghemical.so.0 to libghemical.so.2), were there really
> backwards-incompatible changes? So far, not a lot of software is using
> mopac or libghemical so it does not matter much as I/we maintain all
> anyway, but if application developers cannot target stable APIs, they
> will not attract a lot of hackers.

I think you're seeing this backwards: it isn't a case of "breaking
API", but rather of keeping same API (apparently) but changing the
SONAME as if it *were* incompatible. So you'd have a
libghemical2-dev/shlibs that happens to be compatible with
libghemical0-dev/shlibs...no big deal, other packages are free as
usual to pick whichever libversion package they want, just like usual
when there are multiple libversions of a shared library. Each
libghemicalX still provides a self-stable API, it's just that X=0
happens to be compatible with X=2.

> Of course, if there was a valid need to break the API, that is fine, but
> I suspect it was simply the coupling of library version to package
> version, which is usually the wrong thing to do.

OTOH, yes, this is not the best way to do things; libtool provides
specific flag variables that one adjusts depending on what type(s) of
changes one makes, and then SONAME vs invisible teeny-version and
bug-fix changes and backwards-compabible interface changes all "just
work". Gets a bit dicey, given that there are already apparently
weirdly (or at least "non-standardly") versioned things out there, so
just gotta make sure things don't get worse when fixing them.

dan

-- 
Daniel Macks
dmacks at netspace.org
http://www.netspace.org/~dmacks