[geos-devel] Re: Versioning scheme, binary compatibilities and future of GEOS

[strk at refractions.net]

On Mon, Dec 19, 2005 at 01:15:07PM +0100, Eric Faurot wrote:
> Hi,
> 
> (I did not follow-up because I just subscribed to the list, sorry)
> 
> I'm packaging GEOS/PostGIS for OpenBSD (btw, I have a few minor
> patches for GEOS and PostGIS; I'll post them later).  It might be too
> late, but as you asked for opinions I'll give my BSD-biased point of
> view. Not that it is worth a lot but...

Plese send postgis patch quickly as release date for 1.1.0 
is set to this wednesday (might be delayed for this need).

> First, if your plan is to encourage people to use the C API, then why
> not use libgeos.so and libgeos++.so for the C and C++ library
> respectively? It makes things simple and clear. The transition might
> be a bit painful, but if the C++ library becomes "sort of internal",
> the name change would not hurt too much anyway.

I agree this would be better, but unfortunately libgeos_c.so is
already out there (starting at geos-2.2.0), and many applications
already use geos.so expecting a C++ interface. If community 
screams enough for this I'll take it in consideration.

> Concerning the library versioning scheme, if the C++ library is
> incompatible between each release then I suggest either to change its
> name completely each time, (libgeos++-3.0.0.so instead of
> libgeos++.so.3.0.0) or better, bump the major version for each release
> (libgeos++.so.4.0, libgeos++.so.5.0 libgeos++.so.6.0, ...).  The
> second scheme is really the best, because it allows to keep the same
> C++ version number for a "trivial fix" releases, or changes that do
> not affect the C++ code. And it does not bind the library version to
> the release, which was your original goal.

Renaming completely is what happens with the -release flag of libtool.
Indeed release 3.0.0 will dump libgeos-3.0.0.so.

Using major numbers would allow keeping some form of compatibility,
but the whole point is reducing cost of traking this, which is
feeling free to break ABI for the sake of speeding up the operations.

Always increasing Major would just be aestetically unpleasant, and
would also make it harder to find out which release does a library
come out from.

> About the C API, well, I don't find the libtool versioning framework
> very interesting and practical.  Note that BSD linker only knows about
> the major and minor numbers. A program can link to a library if it has
> the same major number and a minor number smaller or equal than the
> library. Three-number schemes do not fit.

Yeah, I noticed that. On *BSD systems GEOS-2.1.0 produced libgeos.so.3
and GEOS-2.2.0 produced libgeos.so.4, preventing automatic use
of the Minor releases from already built executables.

At a first glance I supposed this was due to possibly limited *BSD
capabilities (something about symbol relocation?). Do you know, as
an OpenBSD user why does libtool acts like that ? 
Also, I didn't check if behaviour is the same for C libs (compared
to C++ ones).

> My 2 cts.

Thanks for that.

--strk;

 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII.