
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>

<p>Hi Even and others,</p>

<p>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.</p>

<p>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?</p>

<p>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.</p>

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

<p>Greetings,</p>

<p>Andreas</p>

<p id="reply-intro">On 2020-02-06 16:03, Even Rouault wrote:</p>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">Now, I'd like to find out under which circumstances QGIS.ORG would be<br />willing to officially support QGIS LTR version for 2 years.</blockquote>

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

</blockquote>

<p><br /></p>


</body></html>