[gdal-dev] Motion: Promote GDAL 3.0.0 rc2 for release

[Even Rouault]

Robert,

> 2. If we're bumping a major version, shouldn't we take that opportunity to
> swap some other backwards-incompatible defaults rather than wait for
> several more years to do it? Off the top of my head I'm thinking things
> like:
> 
>    - Python's UseExceptions() defaulting to true

I bet upgrading autotest for that will be painful (unless we use 
DontUseExceptions()). There might be impacts on GDAL python utilities that can 
recover from some errors by testing for None (I wouldn't necessarily trust 
autotest to uncover all those. Careful code review will be needed)

>    - Python's object lifecycle management (I guess in theory this can be
>    fixed in a compatible way?)

Unfortunately no. From my memories from many years ago when I looked at that 
(there must a patch attached to some Trac ticket), if you do currently

ds = gdal.Create(filename, ..)
band = ds.GetRasterBand(1)
ds = None
os.unlink(filename)

that will succeed on Windows. If we fix reference counting, then the band 
object will still maintain the C++ GDALDataset object opened, and the unlink() 
will fail. This is/was a common pattern in autotest.

>    - GeoJSON defaulting to 2008 instead of RFC7946
>    - I'm sure there's a pile of others.
> 
> Feels like 3.0 has been chosen for good reasons, but without stepping back
> to go "what other longstanding warts do we want to address at 3.0?". I
> don't know if there's a major rush on to get a release out in time for some
> cutoff date? Otherwise I suggest we take an opportunity to step back and
> swap some odd defaults that have been hanging around for years for
> compatibility.

I'd like GDAL 3.0 to be out soon. Most Linux distros can't ship PROJ 6 until 
GDAL 3.0 is released, since PROJ 6 + libgeotiff 1.5 + GDAL 3.0 are kind of a 
combo.

Nothing prevents us from deciding that 3.1dev will be released as 4.0

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com