Re: [MetaCRS] Motion: Adopt libgeotiff 1.4.1RC2 as 1.4.1 Release

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: [MetaCRS] Motion: Adopt libgeotiff 1.4.1RC2 as 1.4.1 Release

Howard Butler-3

On Sep 17, 2014, at 10:36 AM, Charles Karney <[hidden email]> wrote:

> On 2014-09-17 02:51, Frank Warmerdam wrote:
>> Folks,
>> 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
>> 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,
>  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

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.

I'd be happy to incorporate that. I presume it'll be awhile before there's another geotiff release though.
Geotiff mailing list
[hidden email]