[gdal-dev] GDAL 2.5.0 beta1 available

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

>> I would expect then that packaging systems will hold off on this,
>> because I don't think we've reached the point that the collateral damage
>> of upgrading proj to 6 is ok.
>
> Packaging systems with an experimental staging area should be able to package 
> it hopefully, and add it to the other packages supporting PROJ 6 already.

True, but that's separate from what is in the mainstream distribution.

>> With any luck I'm wrong and most of the proj-using packages have had a
>> release that works on 6, but it seems that there are a lot of packages
>> not yet able to cope.
>
> I understand your concern, but what would have be supposed to do: wait for 
> others to upgrade to PROJ 6 as well and defer until they did :-) ?
> We're tracing the road away by adopting PROJ 6 too. Projects which don't 
> follow the trend are doomed to be left aside ultimately.
>
> Sorry, supporting older PROJ versions wasn't really wishable from a GDAL 
> maintainability point of view. What happened is a deep change. A lot of code 
> has been """moved"""" to PROJ: instanciation of CRS from the EPSG database, 
> WKT1 support, ESRI WKT support and PROJ string import/export. Actually, all 
> that code has been deleted from GDAL and rewritten in a completely different 
> way in PROJ. Supporting older PROJ versions in GDAL 2.5 would mean maintaining 
> a lot of ancient code, that behaves in subtle different ways. Would be a mess 
> to have the test suite working in both mode, etc. GDAL is a complicated and 
> big enough beast like it is already.

I can certainly see your point that supporting 5 and 6 in the same
release is too much.  I didn't really mean to sound like "you should not
have done this".  I was just trying to point out that the 6-only status
of 2.5.0 is likely going to lead to quite delayed adoption in packaging
systems.