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

[Robert Coup]

Hi Even,

Oh, I know nothing is super-easy and it takes non-trivial time to make
these changes. And (I looked) there doesn't seem to be a good
pending-deprecation/defaults-to-change list ready to go either, which is
why those 3x were off the top of my head.

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.


Understood, makes sense.

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


User attention is finite though — see my reply to Jukka.

Anyway, I thought  it was worth bringing up :)

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)


Feels to me like for things we know are deprecated (ie. everyone should be
using UseExceptions()) that the GDAL codebase + tests should use the common
behaviour and only test the old way strictly for compatibility (not
functionality).

Thanks,

Rob :)

On Wed, 8 May 2019 at 11:36, Even Rouault <even.rouault at spatialys.com>
wrote:

> 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
>


-- 

Chief Technology Officer Koordinates

+44 759 987 3480 <+44%20759%209873480> / koordinates.com / @koordinates
<https://twitter.com/koordinates>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20190508/35f42a72/attachment.html>