[QGIS-Developer] Next QGIS LTR and its compatibility with older versions

[Greg Troxel]

Andreas Neumann via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> 3.34 will be the next LTR, but not yet in October 2023, but only
> starting from end of February 2024. In the table
> https://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule
> you can check the third column labeled "Long-Term Repo" to see at what
> time frame which version is LTR.

While we are on the subject, I have a packaging question.  I maintain
the qgis package in pkgsrc, a packaging system supporting multiple
operating systems, releases of those systems, and CPU types.  Currently
qgis is at 3.28.11, because I am tracking LTR.

I have avoided trying to have both LTR and non-LTR in pgksrc.   I have
guessed that LTR is more in the interest of random users.  But I am not
the least bit sure if that's right.

(Also, qgis LTR is nowhere near what LTS packaging needs.  LTS packaging
is generally 5 years.  I am not criticizing qgis for this, just being
clear; my view is that people who want to run old code for 5+ years with
fixes should pay for that maintenance and not ask open source project
volunteers to do it for them).

I understand that the non-LTR branches have limited support lifetimes,
but pkgsrc has no aspect of LTS (we have releases every quarter and no
support for old releases at all).  So the fact that 3.32 will become
unsupported when (3.34.0 is out | 3.34 is recommended for general use)
is not important to us.

My impression is also that 3.30, 3.32 are stable and entirely usable for
users.  It's merely that one jumps branches 3 times as often.  Of course
this is more difficult in a multiplatform environment as qgis saves
projects in the current version, not the version that was opened, so
everybody needs to be on the same version.

So, assuming our users are mostly individuals (if they are companies
they should have an IT shop and help with maintenance :-), is there any
reason I shouldn't have pkgsrc track the most recent
generally-recommended version?

What do other packaging systems do, that aren't explicitly LTS?   LTR
only, stable only, both?  I would appreciate hearing what you do and why.

> About your second question: don't nail me down on this but all 3.x
> versions should open with the newest 3.x version - it should be even
> possible to open version 2 files with the latest 3.x version.

As a data point, I have been tracking LTR via pkgsrc and never had an
issue opening.

However, every time a project is saved, it is written with the version
currently running, so once you do that, I expect it would be at least
some trouble to try to read it with the older version.  However, I have
never tried to do that.