make liblwgeom compatible between micro releases

[mwanner]

As it currently stands, liblwgeom does not provide backwards compatibility to older micro version releases, i.e. liblwgeom from 2.0.3 doesn't claim to be backwards compatible to liblwgeom built from 2.0.2 (even though it is). This is rather unfortunate from a packaging standpoint, because it requires recompilation of all dependencies for every micro version release of liblwgeom.

Thus, I'd like the Postgis developers to think about changing the SONAME from liblwgeom-2.0.3.so to liblwgeom-2.0.so (or maybe just liblwgeom-2.so) and maintain backwards compatibility between patch releases (or, preferably, even between minor version releases).

The effective SONAME change is a single line patch. The beefy part of this is actually maintaining the required level of compatibility. However, to provide some data, I scanned backwards a bit: 2.0.1 seems to be compatible to 2.0.0. liblwgeo-2.0.2 is not because it removes ptarray_point_in_ring(). The 2.0.3 release is compatible, again, it doesn't even add any symbols compared to 2.0.2 [ Of course, that's only comparing symbols, not testing semantics. ]

[robe]

huh this is nasty.

strk, Remind me again why you wanted to do this. Shouldn't we have forked a separate project for this so that PostGIS wouldn't have to be held hostage to these concerns?

[mwanner]

Nasty? Moving code to a library and thus making it usable for others is a good thing, IMO.

Held hostage? That seems harsh for a bit of versioning sanity. Or do you anticipate playing marketing games with your version numbers? Granted, a separate liblwgeom project would allow to have different version numbers. But separation certainly doesn't help with keeping liblwgeom backwards compatible. (A concern that's already inherent to PostGIS to some extent.)

Bottom line: In the end, I'm happy either way. For the 2.0.x series, a SONAME change seems easier to do, while separating the projects doesn't look feasible to me.

[strk]

See #1220 for a task that's known to break backward compatibility, and #1159 for further work. We'd better clean up the API (reduce it) before going public, or we'd break things very soon after.

[robe]

Yes NASTY if you don't plan to support it as a separate entity. It's just irresponsible in my book.

The problem is that liblwgeom was private to PostGIS so versioning is very different for our purposes. Our versioning simply means OUR public interface will never change within minor of PostGIS (which is the SQL interface) (not that something private to us (liblwgeom) will NEVER change). Now people rely on the version numbers of liblwgeom to mean something and abide by some saneness of numbering (e.g. the minor is stable). We're just not grown-up enough for that yet.

[mwanner]

As it stands, liblwgeom provides a SONAME that changes not just with minor releases, but with every micro version increment. Making micro version releases of liblwgeom incompatible. Anybody relying on liblwgeom-2.0.4 being backwards compatible to liblwgeom-2.0.3 doesn't understand library version concepts - and shouldn't ever blame PostGIS. I fail to see anything nasty, here.

This ticket is a request to change that, as it's required to make liblwgeom usable to external projects. As strk and robe both point out (in different ways) there are other issues that need to be resolved, first. Basically defining an ABI that PostGIS (or a separate liblwgeom project team) is willing to provide and support.

[robe]

strk and while you are at it. If you really want to make it easy for people to use this, it should be able to compile separately from postgis (not requiring you have to compile PostgreSQL first).

I can't believe the other Sandro has to go thru this much effort to use it. He must be really patient or some sort of super hero.

​http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html#liblwgeom

BTW: he has the same problem that it builds statically for him too under mingw64

and others ​http://gis.stackexchange.com/questions/48495/how-to-compile-liblwgeom-independently

[strk]

To more years has passed, maybe we grew a little bit more now. I'd be ready to start patch-level compatibility with 2.2.0 (we always have liblwgeom_internal.h to play our tricks, if we want them).

PS: Sandro Furieri is now happy with building (adding him in Cc) - Sandro: do you have an osgeo nickname to use for Cc fields ?

[Bas Couwenberg]

Now that SpatiaLite recommends packagers to enable the liblwgeom features (​1, ​2), addressing the liblwgeom library versioning has become more relevant again.

I'd love to see the patch-level compatibility in PostGIS 2.2, so that we don't have to rebuild spatialite every time a new postgis patch version is uploaded to the Debian archive.

[robe]

I know we said only bug fixes in 2.2 after feature freeze call, but I proclaim this to be a bug and not only do I want patch level compatibility, I want the name to be consistent with the rest of PostGIS proper (which means no micro taked on to the end of the .so/.dll file). Actually that part is more important to me.

First of all, now that I've got this extra liblwgeom*.dll following me around in 2.2 (and my shp2pgsql-qui, shp2pgsql, pgsql2shp now depend on it), to add insult to injury, it has the nerve to tack on a micro on the name so it's liblwgeom-2.2.0dev.dll in 2.2.0dev. This was not the case in 2.1 for me. So this is a PITA for (at least for windows distribution, I imagine for others as well) since old cruft is left behind when people upgrade to a micro. If liblwgeom is going to be shared, then its got to have the same version .so/dll name as PostGIS proper (which means NO .micro at the end)

[strk]

r13855 switches liblwgeom versioning to interface current:revision:age model. We start with interface 4, of age 2 and revision 0, meaning a numbering of 2.2.0. The interface version is derived from Version.config so there's no additional settings to tweak.