[QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Even Rouault]

> 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