qgis / QGIS-Enhancement-Proposals

QEP's (QGIS Enhancement Proposals) are used in the process of creating and discussing new enhancements for QGIS

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

2-Year LT versions (OSGEO4W and Mac builds)

andreasneumann opened this issue · comments

QGIS Enhancement: 2-Year LT versions (OSGEO4W and Mac builds)

Date 2021/02/02

Author Andreas Neumann (@andreasneumann)

Contact andreas at qgis dot org

Version(s) QGIS 3.16 and later

State of the Proposal Draft - open for discussion.

Summary

Discuss how the supported life-span of an LT version can be extended from one year to two years. This proposal is limited to the Windows version (OSGEO4W).

Reasoning: larger organizations need more stable releases with longer time-spans for bug fixes. Such organizations typically do not install the normal 4-month-release versions, but only the LT versions. In addition, such organizations typically install new LT releases approx. half a year after the initial release, in order to get a more stable QGIS release. This means, the time windows in order to get additional bugs fixed is really short. This proposal enables for such organizations to get a longer time-frame for additional bug fixes.

Proposed Solution

  • The QGIS release schedule of regular 4-month releases is not changed. But the support and release period of a QGIS LT release is extended to 2 years.
  • The github branches for LT versions should remain open for bug fixes for 2 years.
  • A new LT version is released every second year only (no overlapping of LT versions, see discussions below)
  • QGIS.ORG bug financed bug fixing only happens during the first year of an LT version
  • Any additional bug fixing in the second year of an LT version needs to be financed differently, e.g. by contracting with a company providing QGIS support.
  • Base libraries (GEOS, GDAL, Qt, etc.): It is suggested to keep only one set of base libraries for both the regular release versions and the LT versions, unless a new library version introduces an API break, in which case we need to support two separate sets of base libraries. Reasoning: fewer efforts to support separate library sets and the fact new library versions usually fix more bugs rather than introducing new bugs. See discussions below.
  • QGIS.ORG continues to release the minor LT versions (bug fix releases) with the regular intervals for the second year of the life-time of an LT version.

Potential problems

  • additional packaging work
  • more complex system with different base-library versions in case of an API break

Votes

(required)

I believe that MacOS packaging is thanks to the last year refactoring prepared to do this with relative ease (PR and LTR have already different base libraries ATM)

In the PSC meeting it was suggested to remove the overlapping of LT versions and only release the LT version every 2 years:

This sentence is removed:

LT versions are still released yearly, but similar to Ubuntu LT versions, the life time of LT releases overlap for one year. (To be discussed if we should change that to a release of LT versions only every second year, with no overlap)

About separate versions of base libraries:
@jef-n suggests to keep only one version of base libraries for both regular releases and LT versions, unless there is an API break happening in the respective library. Reasoning: newer library versions usually fix issues and as long as there are no API breaks, the risk of breaking things through newer library versions is rather smaller than the benefits the new versions bring.

What should be decided about Linux builds? Is this out of our hands/control what they do?

@andreasneumann

In the PSC meeting it was suggested to remove the overlapping of LT versions and only release the LT version every 2 years:

Is that a final decision or just a suggestion? I think a two year wait for organisations to get new features into an LTR is a very long time, and potentially a blocker for some QGIS investment...

QGIS.ORG continues to release the LT versions with the regular intervals for the second year of the life-time of an LT version.

What this sentence means?

It means that e.-g. we will have: ?

  • one LTR for 2020-2022 (2-years)
  • one LTR for 2021-2022 (1-years)
  • one LTR for 2022-2024 (2-years)
  • ...

@andreasneumann

In the PSC meeting it was suggested to remove the overlapping of LT versions and only release the LT version every 2 years:

Is that a final decision or just a suggestion? I think a two year wait for organisations to get new features into an LTR is a very long time, and potentially a blocker for some QGIS investment...

@nyalldawson we discussed that but the general consensus was that having two versions tagged as LTR at the same time could be confusing for the users.
There is also the additional cost of maintaining and backporting patches to one more branch.

But nothing is carved in stone, we can discuss it further.

@sbrunner - sorry - that was badly formulated. I changed it into

QGIS.ORG continues to release the minor LT versions (bug fix releases) with the regular intervals for the second year of the life-time of an LT version.

to make it clearer. What I mean here is that in the second year of the LT version, additional dot releases (minor bug fix versions) would be released.

QGIS.ORG continues to release the LT versions with the regular intervals for the second year of the life-time of an LT version.

What this sentence means?

It means that e.-g. we will have: ?

  • one LTR for 2020-2022 (2-years)
  • one LTR for 2021-2022 (1-years)
  • one LTR for 2022-2024 (2-years)
  • ...

Is that a final decision or just a suggestion? I think a two year wait for organisations to get new features into an LTR is a very long time, and potentially a blocker for some QGIS investment...

@nyalldawson - personally I would be in favor of the overlapping LT versions, but the majority of the PSC convinced me that this would be a) confusing and b) too costly.

About a) I think this is a "non issue". Other software packages (Ubuntu, PostgreSQL) also have overlapping LT versions.

About b) - yes, it would be additional efforts.

Not a lot has happened on this topic - and I don't have the energy and pressure (from my employer) to continue working on this anymore ( and I haven't invested a lot so far anyway ).

If someone else wants to pursue this, you are welcome to do so.

@andreasneumann @elpaso @PeterPetrik @nyalldawson I'm sorry for interfering with your conversation. I'm only a QGIS user, not a contributor/sponsor. But you can choose a middle option, the average between 1-year and 2-year support periods.
The LTR release should be every 4th release, not every third like now. In this case, the support period will be 16 months. And the last LTR point release will be 3.x.19

During the developer meeting, we have been a lot exploring Blender's project website, and there are a few interesting points :

  • Their release cycle is 3 monthes (so 4 per year)
  • LTR versions lasts 2 years and receive only critical fixes
  • They have very clear "BCon" phases for each release, defining which operations are allowed from introducing new feature, bugfixing effort ratio vs developping, freezing, release effort, etc. Really interesting IMO, not that far from what we do.
  • They release new LTR minor version only if at least a "severity 1" issue is fixed. "Severity 2" fixes pile up until the next release. This probably limits the amount of packaging work we have every month.

For more details https://wiki.blender.org/wiki/Process/Release_Cycle

The next LTR will have point releases only every 4 months (with a new release; see roadmap) and will get semi-automatic testing.