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

Even Rouault even.rouault at spatialys.com
Wed May 8 06:23:55 PDT 2019


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


More information about the gdal-dev mailing list