> QGIS LTR in Windows has also switched from proj 5.x and gdal 2.x to > proj 6.x and gdal 3.x which has resulted in some new bugs.
I see 2 different situations: - 3.10 was intended to work with GDAL 3 & PROJ 6 (work started with 3.8 if I remember). OSGeo4W received a late upgrade to them because GRASS 7.8 wasn't ready yet for them (no offense to the GRASS team !), but devs have been able to work against GDAL 3 & PROJ 6, so that wasn't unknown territory. Probably that 3.10.0 could have been delayed while OSGeo4W hadn't switched to GDAL 3/ PROJ 6, but it wasn't clear when GRASS would be out. So overall how the situation was handled doesn't seem that bad for a release exercising new major dependencies. - I do agree that the switch to GDAL 3 & PROJ 6 for a near end-of-life 3.4 LTR was unfortunate (but more than the timing, that does not seem appropriate for a release which was not designed originally to work with them) and I felt -0 on that. > It will be additional work for package managers and more resources, but it > will be good to have some guidelines on LTR and PRs dependencies for > packaging. Each LTR should ideally have its own set of dependencies, allowing controlled changes of them when needed (adopting a new bugfix version might be OK), and allowing the current version to use more aggressively new versions of the dependencies. That said, I'm not a packager, and don't know the effort & cost associated, but that's clearly an area where the project could/should invest. Similar situation is likely to happen again in the future. I'm also wondering if there shouldn't be a vote, from developers, PSC, bug triagers, testers or probably a mix of them forming a representative body, to adjudicate: - dependency upgrades - decision of releasing a new version (most other OSGeo projects I'm familiar with rely on a PSC formal vote to issue releases (*)). Or one might consider a mixed approach to have a good compromise of agility vs tighter control: - use time-based approach, as done currently, for non-LTR versions. - formally approve the release of LTR versions, and important engineering decisions that affect them, as there are the ones with the most user exposure. Sometime ago I also suggested to possibly consider 2 phases in a LTR life- cycle: first half where quite "aggressive" backporting is accepted (if it doesn't break API, etc..), second half where a much more conservative approach is taken. It is rather obvious that a .0, .1 needs more stabilization than a . 12 or a .13 Just food for thought :-) Even (*) even bugfix ones, which is admidetly sometimes a bit overkill -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
