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

[Kristian Evers]

I mistakenly erased the title in the last email. Here’s my response below added to the correct thread.

Sorry for the noise.

/Kristian

On 7 Feb 2020, at 07:39, Kristian Evers <kreve at sdfe.dk<mailto:kreve at sdfe.dk>> wrote:



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…

We’ve decided to extend the lifetime of the old API for the PROJ 7 release cycle [0]. So it will not
be PROJ that gives QGIS 3.4 the kiss of death. The decision was made to avoid situations like
this.

Even and Nyalls point above of course still stands. With the many dependencies QGIS has this situation
will come up sooner or later.

/Kristian

[0] https://lists.osgeo.org/pipermail/proj/2020-January/009289.html

_______________________________________________
Qgis-psc mailing list
Qgis-psc at lists.osgeo.org<mailto:Qgis-psc at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/qgis-psc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20200207/4b2fa0fd/attachment.html>