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

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Even Rouault-2
Hi,

Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final release.

-------

My vote: +1

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

jratike80
+1

-Jukka Rahkonen-



Even Rouault-2 wrote

> Hi,
>
> Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final
> release.
>
> -------
>
> My vote: +1
>
> Even





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

Tobias Wendorff
In reply to this post by Even Rouault-2
+0.9999998


Von einem iPhone gesendet und wird daher Fehler enthalten.

> Am 07.05.2019 um 11:19 schrieb Even Rouault <[hidden email]>:
>
> Hi,
>
> Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final release.
>
> -------
>
> My vote: +1
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

jmckenna
Administrator
In reply to this post by Even Rouault-2
+1 jeff




On 2019-05-07 6:19 AM, Even Rouault wrote:
> Hi,
>
> Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final release.
>
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

Howard Butler-3
In reply to this post by Even Rouault-2


> On May 7, 2019, at 4:19 AM, Even Rouault <[hidden email]> wrote:
>
> Hi,
>
> Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final release.
>
> -------
>
> My vote: +1

+1

Howard

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

Daniel Morissette
In reply to this post by Even Rouault-2
+1

Daniel

On 2019-05-07 05:19, Even Rouault wrote:

> Hi,
>
> Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final release.
>
> -------
>
> My vote: +1
>
> Even
>


--
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

Sean Gillies-3
In reply to this post by Even Rouault-2
Excellent, Even. Thank you for the version name change. 

On Tue, May 7, 2019 at 3:19 AM Even Rouault <[hidden email]> wrote:
Hi,

Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final release.

-------

My vote: +1

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev


--
Sean Gillies

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

Robert Coup
In reply to this post by Even Rouault-2
Hi all,

On Tue, 7 May 2019 at 10:19, Even Rouault <[hidden email]> wrote:

Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final release.
 
(I'm not a PSC member)

1. I agree with bumping to 3.0 with the significant changes

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
  • Python's object lifecycle management (I guess in theory this can be fixed in a compatible way?)
  • 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.

Cheers,

Rob :)

--

Chief Technology Officer Koordinates

<a href="tel:+44%20759%209873480" target="_blank">+44 759 987 3480 / koordinates.com / @koordinates


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

jratike80
Hi,

Even answered in a mail on Thu May 2 00:43:37 PDT 2019:

"Well, I was about *releasing* the version, and don't intend to postpone it
significantly, so no there won't be any surprise last-minute changes than
the
ones already documented in MIGRATION_GUIDE.TXT. After all, major version
numbers are cheap, so if during the next dev cycle 3.1dev turns out to need
API breaks, it will be 4.0 ..."


-Jukka Rahkonen-



Robert Coup wrote
> Hi all,
>
> On Tue, 7 May 2019 at 10:19, Even Rouault &lt;

> even.rouault@

> &gt;
> wrote:
>
>>
>> Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final
>> release.
>>
>
> (I'm not a PSC member)
>
> 1. I agree with bumping to 3.0 with the significant changes
>
> 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
>    - Python's object lifecycle management (I guess in theory this can be
>    fixed in a compatible way?)
>    - 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.
>
> Cheers,
>
> Rob :)
>
> --
>
> Chief Technology Officer Koordinates
>
> +44 759 987 3480 <+44%20759%209873480> / koordinates.com / @koordinates
> &lt;https://twitter.com/koordinates&gt;
>
> _______________________________________________
> gdal-dev mailing list

> gdal-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

Even Rouault-2
In reply to this post by Robert Coup
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
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

Robert Coup
In reply to this post by jratike80
Hi Jukka,

On Wed, 8 May 2019 at 11:26, jratike80 <[hidden email]> wrote:

Even answered in a mail on Thu May 2 00:43:37 PDT 2019:

"Well, I was about *releasing* the version, and don't intend to postpone it
significantly, so no there won't be any surprise last-minute changes than
the
ones already documented in MIGRATION_GUIDE.TXT. After all, major version
numbers are cheap, so if during the next dev cycle 3.1dev turns out to need
API breaks, it will be 4.0 ..."

Sure, numbers are cheap, but requiring users to stop & take the time to work through their codebases to check for and address a set of incompatible changes are the opposite — I don't think we want to be continually doing that.

For us at least, GDAL minor X.Y -> X.Y+1 upgrades are relatively straightforward: read the changelog, review things that look possibly problematic, reapply any patches we still need, build, run our test suites, QA, stage through to release.

I'm not majorly hung up on it, just something I wanted people to consider

Rob :)


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

Robert Coup
In reply to this post by Even Rouault-2
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 <[hidden email]> 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

<a href="tel:+44%20759%209873480" target="_blank">+44 759 987 3480 / koordinates.com / @koordinates


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

Even Rouault-2
On mercredi 8 mai 2019 12:07:00 CEST Robert Coup wrote:
> 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.

That reminds me of some recent tweet I saw which said that having a todo list
was not necessarily a good idea and had the effect of discouraging
contributions: people could take it for granted that someone was going to
implement them and there was funding backing those ideas. That said, part of
https://trac.osgeo.org/gdal/wiki/GDAL20Changes is probably still valid (at
least from a technical point of view. Not necessarily things we really want/
need to change)

Anyway regarding 3.0 release, I would also have preferred to know in advance
this was going to be 3.0 rather than at the last minute, so there was
opportunity to slip other things into it. Partly my own fault since I should
have anticipated that at RFC73 time. Partly community fault to not have raised
that earlier too (the breaking changes were mentionned in the RFC)

The thing is that it is difficult to plan the content of a major release since
a lot of the ideas that make a major release are not 5-minute changes, and so
require to have secured availability/funding for them in advance. And a number
of breaking changes will be welcomed in different ways depending on users.
Existing users (who are the most likely to be able to fund changes since they
depend on the software and thus can make a case it contributes to their chain
value) don't necessarily need them since they are happy with existing things
(or have coped with them). They are more for new users who haven't yet adopted
the software and stumble on its historic oddities. At least, that's my own
perception of how things work. There are also changes you don't initially plan
to be breaking and that turn out to be breaking, sometimes in a marginal way,
during implementation. So bumping the major version number is sometimes more a
logical consequence than an intention.

And actually if you look at all the GDAL 2.X releases, all of them have been
breaking in some ways. Just look at MIGRATION_GUIDE.TXT. Most of the time in
ways not detectable at compilation time (the 2.0 -> 2.1 and 2.1 -> 2.2
transitions are examples of that). That could have justify a bump of the major
version number for all of them.

>
> User attention is finite though

My availability as release manager too :-)

There are 2 situations regarding updates:
- you depend on GDAL being shipped with an external distribution mechanism
(Linux distro, OSGeo4W, homebrew, etc.), so you have little choice and must
update whenever a new version is made available
- you build and ship your own GDAL. So you can decide if you do all X -> Y ->
Z transitions, or just X -> Z.

Updating for a lot of breaking changes at the same time can be quite
discouraging. I personnaly prefer incremental upgrades where, before entering
the tunnel, you can already see the light at the other end.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Motion: Promote GDAL 3.0.0 rc2 for release

Even Rouault-2
In reply to this post by Even Rouault-2
On mardi 7 mai 2019 11:19:50 CEST Even Rouault wrote:
> Hi,
>
> Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final
> release.
>
> -------

I declare this motion passed with +1 from PSC members JukkaR, HowardB, DanielM
and myself

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev