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

[Nyall Dawson]

On Fri, 7 Feb 2020 at 01:03, Even Rouault <even.rouault at spatialys.com> 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.

Big +1 to this. Before any decision is made I'd like to see us make a
proper definition of what an "LTR" release actually means. Is it just
that we continue to provide working installers for it for 2 years? Are
we pledging to fix high risk issues only, or any easily backportable
fixes (no matter how important the bug)? Where do we draw the line?

Personally, I stopped backporting fixes to 3.4 late last year. The
effort and trickiness involved in porting them was too high, and I
deemed the risk of doing this to greatly outweigh the benefit of
having a bug fixed in 3.4. In the absence of an official policy here,
I've been suggesting the same for backports others have submitted.

I'll run with whatever policy PSC sets for this, but it needs to be
very well defined in order to avoid any misunderstandings by either
developers or users...

> 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

Right -- as an example as soon as proj 7 rolls out without the older
api compatibility, 3.4 will no longer build (and **CANNOT** be fixed
to do so). So when distros update to this that's the definite EOL for
3.4 support on those distros...

Nyall

>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc