Re: [fluid-dev] SONAME Bump?

[Andrew Suffield]

On Sat, Aug 06, 2011 at 03:20:54PM +0200, Pedro Lopez-Cabanillas wrote:
> On Saturday 06 August 2011, Andrew Suffield wrote:
> > On Sat, Aug 06, 2011 at 10:00:21PM +1000, Matt Giuca wrote:
> > > - Release FluidSynth 2.0, with soname libfluidsynth.so.2, or
> > 
> > It is generally unwise to attempt to keep SONAME versions and project
> > versions in sync. This leads to confusion and inappropriate
> > compatibility problems. Best practice is to keep them entirely
> > separate.
> > 
> > The exception is projects which make no attempt to provide any kind of
> > stable ABI, for whatever reason (usually: code changing too fast,
> > developers can't be bothered). Those have exactly one SONAME per
> > version of the code, and client applications must be rebuilt with
> > every code change to the library.
> 
> IMO the libtool numbering scheme is an unnecessary mystification, to
> say the least.

It's irrelevant here. The standard practice is to simply use a single
integer version in the SONAME and increment it whenever the ABI
changes.

> KDE4 provides a pretty stable ABI, and does not need to use
> libtool. Qt has always managed to provide strongly stable ABIs
> within major releases, without using libtool either.
> 
> Qt4 libraries, as a nice example, keep in sync the SONAME with the
> shared object name and the project version.

They dedicate several people to the task of maintaining a reinvention
of libtool, shared library loading, and bits of C++. I can't recommend
this approach; it works but it's manpower-intensive.

An example of a more normal library would be libX11 or expat.

(Aside: libtool's versioning scheme is ugly but unavoidable; anybody
who attempts to port to the same set of platforms will end up doing
something very similar, and the only way out is to just not support
some of them)