[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