[Qgis-psc] Formal request to extend LTR life span to two years

[Andreas Neumann]

Hi Even and others, 

Thanks for your valuable feedback. I agree with the different phases of
an LTR, from being more aggressive with bug fixing to being more
conservative later on. 

About the situation with dependencies (gdal, proj, geos): I wonder how
other software packages do that who have a longer supported life span? I
am pretty sure that most commercial GIS software packages offer support
>1 year for. Do they typically freeze the dependencies? And maybe backport critical (e.g. security related) issues when necessary? 

Would the gdal / proj / geos projects be open to discuss overlapping
support of the latest versions in their projects? I am talking about
critical issues, not new providers or features. 

Of course, as always, I would also be interested in Jürgen's opinion, as
his work would be affected by this decision. 

Greetings, 

Andreas 

On 2020-02-06 16:03, Even Rouault wrote:

>> Now, I'd like to find out under which circumstances QGIS.ORG would be
>> willing to officially support QGIS LTR version for 2 years.
> 
> A few thoughts:
> 
> One aspect to take into account is how you organize the time for this 2 year 
> lifespan. Some weeks ago I floated around the idea of having 2 phases in the 
> LTR: a first phase where rather "aggressive" backports are allowed to be able 
> to potentially fix design issues in new features, and a second one where just 
> critical bugfixes are allowed given a risk/advantage assessment: a one-liner 
> fix to avoid a crashing bug is OK, but a 1000 line code change to fix a 
> crashing bug in a odd case scenario not. Of course with a number of grey 
> situations in between... With a 2 year lifespan, anyway this will probably 
> become more obvious as the difficulty to backport fixes will increase over 
> time.
> 
> There's also a packaging point of view to take into account (thinking to 
> OSGeo4W in particular). For a 2 year LTR, you likely need to make sure that 
> the dependencies of the LTR are controlled independently of the ones of QGIS 
> master. You might want to decide to update one of the dependencies in the LTR 
> (like upgrading to a new patch release of a dependency), but this must be a 
> choice, not a mechanical consequence of an upgrade of QGIS master.
> 
> Another thought is that some dependencies of QGIS (thinking to GDAL & PROJ) 
> don't have a 2 year life span for a given release, but more a 1 year one.
> 
> Even
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20200206/8c4118da/attachment.html>