The way we used to build an LTS branch is no longer supported on Flathub

[MattF-NSIDC]

The only allowed branches are master and beta, any others won't build. We were previously using branch/lts, but that is no longer supported.

flathub/flathub#5108 (comment)

No there are currently no plans to allow multiple branches for applications other than master/beta. There's no way to show them on the website, most desktop software stores cannot handle this well, cli confuses people if there are multiple versions available, there are costs to running CI and hosting/storage etc.

They used to be allowed but apps started ab(using) them, so they are no longer allowed.

Options to restore the QGIS LTR release to Flathub include:

• Starting a new repository org.qgis.qgis-ltr (could be confusing to users of various stores)
• Release QGIS LTR on beta branch, currently unused on this project (unintuitive IMO, but not disruptive to users)
• Release QGIS LTR on master and move stable releases on to beta branch (unintuitive IMO, in a different way, and disruptive to users)

Original issue text:

---

Currently the latest LTS release is 3.28.9, but 3.28.6 is the latest LTS available on flathub.

I don't know anything about contributing to the flatpak ecosystem yet, but I'm hoping to find time to learn soon and maybe submit a PR to address this.

Looks like this was the last change to the LTS version.

[steko]

The current LTS version is 3.28.13 but the app shows as "no longer receiving updates".

[MattF-NSIDC]

Thanks @aleixpol!

@steko Looking at #331 I think I could open a new PR to make 3.28.13 available. I have to find free time for it though.

When I first opened the issue I was being funded by a grant that would support work on this, but that's not the case anymore (until maybe March 2024).

CC: @mfisher87 (a.k.a. free-time me)

[Neluji]

Hi, it actually looks like the LTS version has to be moved to another branch for the build to work again (currently the version on flathub is 3.28.9).
As far as I understood the process, you (@aleixpol if you have the rights to do so) need to:

1. Move the code to the new branch (maybe stable/lts sounds good as mentioned in Flathub's doc ?),
2. EOL this one by adding the appropriate key in flathub.json,
3. and open an issue in Flathub repo to ask to move the branch.

If all goes well it doesn't looks like such a hassle, and it will be nice to have the latest LTS version on Flathub ^^ (which is actually 3.28.14)

[sonicnkt]

Sorry to push this up again but it would be really great to have an up to date LTS flatpak again.

The Fedora COPR is not maintained any more either and this was a good solution to keep using the LTS Version for compatibility with other users.

[mfisher87]

I attempted to debug the flathub build and it seems the flathub build site is buggy or broken. The failed build for .13 is here:

https://buildbot.flathub.org/#/builders/6/builds/86119

When I click to view stdio or download it, it says there are 17 lines, but the fetched data is 0 bytes. @aleixpol can you suggest any steps for getting around this? If we can't view the build logs, I don't see a way to fix this package.

[mfisher87]

I can see logs in newer builds, e.g this unrelated project: https://buildbot.flathub.org/#/builders/6/builds/110954

Perhaps the issue is that Flathub/Buildbot archived the logs and isn't communicating that in the UI. Not sure how to re-run the build.

[mfisher87]

@Neluji Thanks for your post above! I didn't grok on first read but after more docs-diving I'm on the same page with you now.

As a person without maintainer access, how can I contribute to getting this process started? To the best of my knowledge, it's not possible to propose creation of a new branch through the PR interface. I'll start by creating a new issue on flathub/flathub.

[mfisher87]

@aleixpol looks like the only way to restore the LTS build is to follow this advice:

flathub/flathub#5108 (comment)

Applications aren't supposed to use branches other than master and beta, maybe the maintainer can make LTS available on master and move the current version from master to beta?

What do you think the best way forward is here? This would potentially be disruptive to users, but I think it's also important to provide LTS (they use the term LTR) as an option for installing QGIS, and dropping LTS support seems to be the only alternative.

[mfisher87]

Some more options were proposed in the above-linked thread, and I updated the issue description to better describe the issue as I now understand it.

[sonicnkt]

This is just a copy of my answer in the linked thread:

I think having two different releases on flathub (org.qgis.qgis-ltr and org.qgis.qgis) would be the best solution if flathub limits the channelss to standard and beta.

Having LTR on beta would make no sense and moving the stable to beta would cause even more confusion as you would essentially downgrade users which would result in projects files not opening correctly anymore.

The LTR version is a quite established name. Having the same icon should not be an issue if the name clearly indicates the version : "QGIS Desktop" vs" QGIS Desktop - LTR" . On no platform qgis uses different icons for LTR or Stable.
There is this issue in main repo tho: qgis/QGIS#52298
And i would see a benefit in having different application icons for LTR and Stable, if for example you want to keep both in a dock/launcher that omits the application name. This would be an upstream issue tho imo.

---

This would also have the benefit to have both version easily installed side by side. Something that is not that unusual imo.
For work related projects i use the LTR since that is the version we deploy at the office for more stability. Sometimes i want to play around with the latest features though.

[mfisher87]

That's very convincing, I think I agree with you.

I love the idea of having both LTR and latest stable installed side-by-side, as that way I can better assess future impact to QGreenland!

I'd be really interested to hear reasons not to do that. Already raised was the issue of a confusing application icon, and @sonicnkt responded above ☝️