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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages 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 18, 2014, at 9:30 AM, Charles Karney <[hidden email]> wrote:

> On 2014-09-18 10:10, Howard Butler wrote:
>>
>> 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
>>>>
>>>> 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.
>>
>
> Maybe you meant 2.1.1 (the number assigned by autoconf?)

I have pushed changes to this effect in SVN. Can you please pull them down and report (to me at least) their validity?

>
>>>
>>> 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.
>
> Then the "right" solution, I believe is the assign a separate lib
> version.

Done in SVN.

>
> Incidentally, I notice that the autoconf build doesn't work "out of
> source", i.e., with
>  mkdir BUILD
>  cd BUILD
>  ../configure
>  make
>  -->
> ../../libxtiff/xtiff.c:19:22: fatal error: cpl_serv.h: No such file or directory

Did this *ever* work? I guess I've never tried it, though I do frequently do out of source builds with cmake.

>
> Does anyone care?  (I've switched to cmake so it doesn't really affect
> me.)
>
>>
>>>
>>> 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.
>>
>
> If you can wait until early next week, I can patch the cmake
> configuration to
>
> (1) Assign separate geotiff (1.4.1) and library (2.1.1) versions
> (2) Put the configured geo_config.h in the build tree (not the source
> tree)
> (3) Create and install find_package support

I'd like to wait for this patch to make it in. It is useful and geotiff's release schedule is so long that it will likely be more than a year before it would make it out to packagers. Another week isn't too bad. Does that sound ok Frank/others?

_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
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 22, 2014, at 10:32 AM, Charles Karney <[hidden email]> wrote:

> Here's a patch to r2556 of

Thanks for the update Charles. I have applied it. See http://trac.osgeo.org/geotiff/ticket/69 for more detail.

Frank,

Can you please issue a new RC?

Howard
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
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 22, 2014, at 4:28 PM, Howard Butler <[hidden email]> wrote:

>
> On Sep 22, 2014, at 10:32 AM, Charles Karney <[hidden email]> wrote:
>
>> Here's a patch to r2556 of
>
> Thanks for the update Charles. I have applied it. See http://trac.osgeo.org/geotiff/ticket/69 for more detail.

I have issued an RC3 for download and testing.

http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.1RC3.tar.gz
http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.1RC3.zip

Please report any issues, and if we do not hear of any, I will motion to promote to a release on Wednesday.

Thanks,

Howard


_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
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 29, 2014, at 7:23 AM, Charles Karney <[hidden email]> wrote:

> On 09/28/2014 08:11 PM, Howard Butler wrote:
>>
>> On Sep 22, 2014, at 4:28 PM, Howard Butler <[hidden email]> wrote:
>>
>>>
>>> On Sep 22, 2014, at 10:32 AM, Charles Karney <[hidden email]> wrote:
>>>
>>>> Here's a patch to r2556 of
>>>
>>> Thanks for the update Charles. I have applied it. See http://trac.osgeo.org/geotiff/ticket/69 for more detail.
>>
>> I have issued an RC3 for download and testing.
>>
>> http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.1RC3.tar.gz
>> http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.1RC3.zip
>>
>> Please report any issues, and if we do not hear of any, I will motion to promote to a release on Wednesday.
>>
>> Thanks,
>>
>> Howard
>>
>>
>
> My patch included the creation of some additional files in the
> cmake directory:
>
>  cmake/CMakeLists.txt
>  cmake/project-config-version.cmake.in
>  cmake/project-config.cmake.in
>
> But these didn't make it into the distribution.  Can that be
> corrected?  (git diff gives /dev/null as the old file in these
> cases.)

D'oh. RC updated.

http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.1RC4.tar.gz
http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.1RC4.zip

Thanks again,

Howard
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

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

Howard Butler-3
And for a new record in libgeotiff candidates, I bring you RC5.

http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.1RC5.tar.gz
http://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.4.1RC5.zip

This RC cleaned up another CMake nit. Hopefully that's it. Expect a promotion motion on Thursday.

Howard
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff