Even Rouault <[email protected]> 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. _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
