On Thu, 18 Nov 2021 at 04:46, Bo Victor Thomsen <[email protected]> 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 > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
