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

Eric Faurot eric.faurot at gmail.com
Mon Dec 19 07:15:07 EST 2005


(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...

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.

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.

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.

My 2 cts.

More information about the geos-devel mailing list