> On 2014-09-17 02:51, Frank Warmerdam wrote:
>> I have prepare a release candidate for libgeotiff which I believe is
>> ready to adopt as a formal release. This is an official motion to the
>> MetaCRS PSC to adopt this RC as a final release.
>> Motion: Adopt libgeotiff 1.4.1RC2 as 1.4.1 Release
>> http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.1RC2.tar.gz >> http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.1RC2.zip >>
>> This release includes a variety of fixes (described in the ChangeLog) as
>> well as
>> an upgrade to EPSG 8.5 csv files, and "in code" support for the csv
>> files (cmake
>> builds only).
> Under Linux, the shared library has the same version number as 1.4.0,
> libgeotiff.so.2.1.0. Is this OK? (This is with a cmake build.)
I think this is incorrect. For the CMake build, like the autotools one, I think the so name should be so.3.1.1 We should probably issue a new RC to clean this up.
> Also I find it confusing that cmake says
> set (GeoTIFF_VERSION_MAJOR 2)
> set (GeoTIFF_VERSION_MINOR 1)
> set (GeoTIFF_VERSION_RELEASE 0)
I agree this is messy.
> while the packages says 1.4.0. I presume that the two versions became
> distinct because the so version number had to skip ahead?
> If possible, I recommend that libgeotiff be "branded" with a unique
> version number that tracks its releases, 1.4.1, in this case. The so
> number should be tracked separately.
Yes, I think this is just incongruence with the (dominant and more-used) autotools stack.
> Finally, I can supply a patch to get cmake to generate a "config-style"
> find package script. I'll need a couple of days to do this (and I would
> need to know which the version number find_package should use). It's
> fine if this doesn't make it in in time for the 1.4.1 release.