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

[Matthias Kuhn]

Hi

A very good discussion. Thank you for bringing it to the attention, Andreas.

On 2/8/20 3:19 AM, Nyall Dawson wrote:
>
> So we end up with two classes of LTR users:
> - those who are conservative, upgraded to the LTR only after a 0.4
> patch release, and who expect that at that stage the release will be
> stable and only seeing absolutely critical fixes
> - those who are can only jump to the LTR release at a later (0.8 patch
> release) stage, and who at that time require riskier changes to flow
> into the LTR release.
>
> Both are valid requirements, yet are potentially mutually exclusive.
> We need to keep these both in mind when developing policy about
> user/project handling of LTR releases.

We will need to find a balance between the two here. I think for a 
prolonged lifetime we can also justify to increase the duration of the 
first stage. On the other hand it would also be good to be able to 
deliver a product for testing earlier in the life cycle for example by 
releasing a (bi-)weekly "beta" version during feature freeze. If we can 
convince the QGIS responsible application managers in organisations to 
test earlier this way we can deliver a higher quality .0 final release 
and allow them to migrate earlier. As a nice side-effect I can imagine 
many "hey, did you see what's coming up in the next QGIS version" blog 
posts from power users which would help to bring more people to testing 
the beta versions.

As mentioned earlier, libraries that are used as a basis for the LTR are 
just as important for stability. Key libraries being gdal, Qt, python 
and proj where we will also need to define a "best served with" major 
release that doesn't introduce breaking changes. I am sure we will 
sometimes be in a situation where we cannot fix issues because 
underlying issues are only fixed in new major versions of libraries - 
most likely in Qt. In this case we will need to take the harder route 
and stick to stability and stick to earlier versions - and if it's 
important enough, we will need to work on a closer collaboration with Qt 
to have backports to Qt LTS versions.

For reference, I planned to trigger a survey to get a better idea of our 
users later this year which could help us having a better decision base 
regarding release management. I thought to push this forward in summer 
(when people have experience in migrating from 3.4 to 3.10 and we don't 
have many effects from a 2 to 3 upgrade in the stats anymore), but we 
can as well do it sooner.


- Which QGIS version are you currently using (3.4, 3.10, another LR)

- How often do you upgrade patch versions (monthly, sometimes, never)

- When do you plan to upgrade to the next version

- Size of organisation / installations

- What is the main reason for not upgrading patch releases more often 
(Why should I if everyting just works; Internal testing takes too long; 
Internal application deployment is complicated/expensive; I already 
update every patch release; Patch releases tend to break things; I 
didn't know there are patch releases; Other)

- What is the main reason for not upgrading the main QGIS version 
earlier (Internal testing takes time; Never change a running system - I 
do not trust new releases; Plugins are incompatible; I always wait for x 
patch releases before upgrading out of habit; Other)

- In an ideal world, how often would you prefer to have new LTR versions 
(1y, 2y, 5y, I use every release regardless if LTR or not)

- Do you have a support agreement with a core developer / company to fix 
blocker issues before upgrading


Feedback on it very welcome.


I suspect we will have a good community of people and organisations who 
would be happy if the QGIS release schedule would offer a stable product 
series at a slower pace.

Matthias