Issues with libgeotiff versioning for 1.3.0

[warmerdam]

In libgeotiff 1.2.5 and earlier the library .so name on linux/unix was just based on release version so we had stuff like:

lrwxrwxrwx 1 warmerda warmerda     19 2009-10-08 09:42 libgeotiff.so -> libgeotiff.so.1.2.5
-rwxr-xr-x 1 warmerda warmerda 334264 2009-10-08 09:42 libgeotiff.so.1.2.5

But in trunk we have upgraded to automake/libtool/etc and so we use -version-info when linking and try to follow the libtool versioning recommendations. However, initially a setting of 1:2:0 was incorporated based on a copy from liblas without further consideration. The issue is what is an appropriate setting to use for the 1.3.0 release.

I think one consideration is how packages like debian and perhaps redhat were patching the versioning for their releases - I'm not sure how that was handled.

Advice? I'm making resolution of this a 1.3.0 blocker.

[warmerdam]

On behalf of the Debian packaging Francesco writes:

<frankie> FrankW: let me see
<frankie>   SONAME               libgeotiff.so.1.2
<frankie> which is not 'standard' in any way but i think it's what your geotiff proposes
<FrankW> ok, that is helpful to know.  I'll add it in the ticket.
<frankie> well 2:0:0 should be safe
<frankie> at least to reset versioning
<FrankW> I'm not sure how nasty it would be to introduce an unnecessarily different version.
<frankie> it is quite common
<frankie> versions and api are often async
<frankie> that's at least to reset
<FrankW> But it would force applications linked against 1.3.0 to require 1.3.0 or newer even though there is no *real* reason that would be needed.
<FrankW> right?
<frankie> yes
<frankie> FrankW: does it extend 1.2 API without changing public fuctions/structs?
<FrankW> I will need to do some review, but to the best of my knowledge there are no API changes. 
<hobu> When was the ST_ stuff added?
<FrankW> Just build system, internal implementation and support data files.
<frankie> FrankW: in that case you have to use 1.2.6
<frankie> for the soname
<frankie> err for the solib

[frankie]

I would add that current SONAME is libgeotiff.so.1.2, so any choice different from 1:2:x would violate the previous soname and require a rebuild for applications. If you would adopt now the standard libtool versioning, I would use 2:0:0, with usual libgeotiff.so.2 for its SONAME.

Of course you could still maintain the old choice and use 1:2:6 for v1.3.0 with the same old soname. The versioning changing could be delayed until necessary for future true API changes. Definitively your choice. What I would avoid is 1:3:0 with libgeotiff.so.1.3 because they give the same result of 2:0:0 (soname change) without benefit for versioning standardization. You could also use a libgeotiff.so.1 SONAME with 1:3:0, but that would require rebuilds anyway.

[warmerdam]

As noted in ​http://trac.osgeo.org/gdal/ticket/3309 there has been an abi change in 1.3.0, so I have set the version information to 2:0:0 to reflect this. Change applied in trunk (r1730).