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 gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
