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

[Eric Faurot]

On 12/19/05, strk at refractions.net <strk at refractions.net> wrote:

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

These are actually not really important. The compiler does not
like sprintf and strcpy but that's ok. The biggest trouble is
that regress fails (#62/#63) because infinity is stringified as "Inf"
instead of "inf". Using diff -i in run_regress does the trick. There
is also a failure on macppc (for OGC regression test), due to
slight differences in floats representation. Maybe checking (in SQL)
that the distance to the expected result is small enough would
be better than comparing the output in this case.

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

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

Well, I have libc.so.38.4 and libstdc++.so.40.0 and I don't find that
too disturbing :). Better than libpangoft2-1.0.so.1001.1 anyway. Also,
I suspect some day the ABI will stabilize enough to be kept compabible
between two minor releases, having it bound to a release name will
be a pain then.

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

I cannot speak for the others, but on OpenBSD, it builds libgeos.so.4.1
and libgeos_c.so.1.1 with GEOS 2.2.1, which looks coherent with the
provided INTERFACE_CURRENT and INTERFACE_REVISION. Also, there
is no symlink trick used to make libfoo.so resolve as libfoo.so.3 resolve
as libfoo.so.3.6.

> 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 ?

I think the policy was to keep things very simple: bump the minor number
for incremental ABI/API changes, and bump the major number for
disruptive changes.  The problem is that lots of programmer started
to use libtool without carrying much about library numbering, happily
mixing project version, releases and library names. So some things
are now pretty messy (gtk2 for example).

http://www.openbsd.org/porting/libraries.html

> Also, I didn't check if behaviour is the same for C libs (compared
> to C++ ones).

I think it is.

Thanks,
Eric.