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

[Borys Jurgiel]

Thanks Even! I was mislead by the hard freeze and had an impression 3.10 is 
going to be more stable than it actually was meant to be. I'm often not sure 
what level of predictability we can expect from the official builds and your 
response shreds more light on it.

And, first of all, big thanks to Nyall for working on fixing it!

Regards,
Borys

Dnia piątek, 22 listopada 2019 23:20:49 CET Even Rouault pisze:
> > 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