[QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Nyall Dawson]

On Thu, 18 Nov 2021 at 04:46, Bo Victor Thomsen
<bo.victor.thomsen at gmail.com> wrote:
>
> Hi list -
>
> I've summed up some ideas about have to handle the LTR situation.  The policies is not carved in stone or complete but suggestions for a more stable regime regarding LTR  (and they have probably already been mentioned sometimes by someones before)
>
> However - Policy for LTR releases:
>
> At most one LTR release for every year.
>
> Point releases for LTR every 2 or 3 months.

I'm fine with these

> Point releases for LTR contains only security or bug patches. Never introduce new functionality or change in the user interface ( Translation files might be exempted from this rule)

That's already the rule which is in place. We also have an additional
rules that any non-crash fix, non-data corruption fixes have to go in
a delayed queue were they can only be included in the LTR after
they've been in a stable release for at least a month. (I.e. a fix
would have to be included in 3.22.1 so it gets once month of testing
before it's permitted into the 3.16.15 LTR patch release).

> The supporting libraries ( qt, proj, gdal, ogr etc. ) is covered by the same rules. Only security or bug patches, never introduce newer major versions.
> Major changes in supporting libraries for non-LTR releases is restricted to the release just after a LTR. Thus there will be 3 or more non-LTR releases to stabilize QGIS before next LTR.

This is not so straightforward, for a couple of reasons:

1. QGIS is heavily tied to the underlying libraries, and often bugs
exposed in QGIS need fixes in GDAL/PROJ or GEOS. It would be
unfortunate if an LTR never gets a crash or data corruption fix
because that fix resides in a lower-level library. Similarly there's
situations where I think it IS important that a non-bug-fix library
update gets pushed to a stable release. For example, updates to the
PROJ projection libraries aren't backported to older PROJ releases. A
local agency may release a new local transformation or CRS and mandate
its use in a geographic area... and without a PROJ library update all
LTR users won't see the CRS updates until the next LTR major release.

2. It's not true that older libraries are inherently more stable than
newer library releases. Take the Qt library for example -- sticking
with an older Qt release just means that you're running an older,
unsupported library. There's no bug fixes or maintenance at all for
the older releases, and the ONLY way to get bugfixes from Qt is to
update to the latest major release. (Basically we're trading one set
of older bugs for the risk of a different set of newer bugs! :P )

3. Sometimes library updates are just necessary to keep things running
without breakage. (Eg. when an older library stops working because
some certificate has expired or upstream URL has changed... we've seen
in the past a situation where python package installation was broken
for a time because we were using an older unmaintained Python library
version, and the only solution was to update the python library to fix
the broken package downloads)

So I'm personally -1 to this particular idea.

Nyall


>
>
> The general idea is that the QGIS release following a LTR is a "Big Bang" release: Everything goes.
>
> The following non-LTR releases can introduce new functionality but no changes in the supporting libraries (This rule could maybe be bend a little) . But when you come around to the LTR release you deep-freeze any changes except security- and bug correcting patches
>
>
> Med venlig hilsen / Kind regards
>
> Bo Victor Thomsen
>
> Den 17-11-2021 kl. 08:27 skrev Luca Manganelli:
>
> > [... ]
>
> As an IT administrator in our public organization, I confess that I have packaged and distributed to all PCs the (old) 3.16.4 version. Why? Because with this version there are 0 problems among users and with our customized plugins.
>
> Before the 3.16 release, the other 3.x versions were a disaster, many things didn't work, so before this 3.16, I had distributed 2.x to many users and 3.12 to only few PCs.
>
> In a big organization the most important thing is not, "strangely", the more features a piece of a software has, but the ... stability. Remember that every worker wants a product that... works.
>
> And, the upgrade. The QGIS package is big (the archive is over 320MB) and we have many offices in sloooow networks (2M ADSL... don't laugh, this is the situ
>
>
>
>
>
>
>
>
>
> ________________________________
>
> Comune di Trento
>
> via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221
>
> tel. +39 0461.884111 | www.comune.trento.it
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer