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

[strk at refractions.net]

News from the transition to 3.0.0.

1. FIXED ISSUES:

> 	- GEOS_FIRST_INTERFACE and GEOS_LAST_INTERFACE #defines
> 	  in geos/version.h (I think they should be removed)

Removed, also from geos_c.h

> 	- PostGIS support for the new GEOS versioning scheme
> 	  (1.1.0 will hook on the C api, but 1.0 branch might
> 	   require a bit of attention in the GEOS transition)

Tested with INTERFACE_* removed, it works fine

> 	- geos-config --version output (I think it should print
> 	  release version)

It does already, I give it for good.


2. PENDING ISSUES:

> 	- geos-config --libs (currently adds a -lgeos, might add -lgeos_c
> 	  instead, but I'm unsure about consequences for users - apart
> 	  feeling warned about troubles).
> 
> 	- geos.m4 setting of GEOS_LIBS (see above item)

So, who uses these flags/macros ? I'd like to hear from users about this


3. NEW ISSUE:

- CAPI library versioning

I've been making some tests, with help from PostGIS users, about
downgrading GEOS (3.0.0 to 2.2.1). If libgeos_c.so version doesn't
change (ie: both version have 1.0.1) a side effect of the
GEOS downgrade is that every application linked against the
CAPI will be bound to the older version, rather then on the new.

A working (tested) solution is to always increment CAPI lib version
at every release, even when the CAPI lib has NOT be changed.
The dark side of this is that multiple GEOS installation sharing
the same prefix would take up more space (multiple identical CAPI
libs under different names).

I think we can leave with the duplication, rather then introduce
confusion about what C++ lib is the CAPI linked against
(ldd would show, but filename wouldn't).

Comments ?

--strk;