Reduce number of supported branches?

[smcv]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Suggestion

At the moment, fixing a security vulnerability or other serious bug in Flatpak would require doing 4 releases (1.15.x, 1.14.x, 1.12.x, 1.10.x). That's a lot of compiling and testing, particularly if it has to be done under embargo for a security fix, and the maintainers' time is limited (I'm responsible for a lot of other projects, and I'm sure the same is true for the other maintainers).

I think we should reduce the number of supported branches to 2 or maybe 3 (1.15.x, 1.14.x and maybe 1.12.x). Next time there is a security issue that affects 1.12.x and 1.10.x, we should still do a release on those branches, but we should also announce that it is likely to be the last release on those branches.

1.12.x is in RHEL 9, and its derivatives like CentOS. It's also the version in Ubuntu 22.04 'jammy', but Ubuntu doesn't normally take our stable releases anyway: if there's a security vulnerability, then Ubuntu usually backports individual patches instead of using an upstream release (which is more likely to introduce unfixed regressions, but that's their choice). Does RHEL similarly backport changes, or does RHEL follow our (old)stable release series?

Are there other LTS distributions that particularly care about 1.12.x? If I understand correctly, EndlessOS is still on 1.12.x, but they already have significant backported changes?

1.10.x is there to support Debian 11 and the RHEL 8 family, but I think we might have reached a point where backporting individual patches into those is more realistic than doing a new upstream release for their benefit?

[smcv]

Or, we could consider having a policy like this:

• the development branch (1.15.x) gets security fixes released as soon as possible after the vulnerability is public;
• the stable branch (1.14.x) gets security fixes released as soon as possible after the vulnerability is public;
• old stable branches (1.12.x, 1.10.x) still have releases, but security fixes only get released when someone gets round to it (releases for these branches don't block lifting embargo on a security vulnerability), and if LTS distributions value these branches then they need to help to do the work

[debarshiray]

I am working on rebasing the Flatpak stack in CentOS Stream 8 to flatpak-1.12.x and friends to match what's in CentOS Stream 9 and RHEL 9 today. If successful, it would land in RHEL 8.10.

[nanonyme]

Makes sense. If you have enterprise distros using very old versions of flatpak, I would expect them to have security teams who can backport fixes. In best case even upstream their backports.

[smcv]

What I say in dbus is: I maintain the current development branch, the current stable branch, and sometimes one older stable branch (but only because I happen to need it with my Debian hat on); and if maintainers of LTS/enterprise distros want to collaborate on backported patches for EOL stable branches, they are invited to join the maintainer team and push their backported fixes to the appropriate dbus-1.x branch, but should not expect any further releases from those EOL branches to happen.

(Nobody has actually taken me up on that offer in practice, but the offer remains open.)

I think that's a reasonable policy to have in other projects like flatpak.

[debarshiray]

Makes sense. If you have enterprise distros using very old versions of flatpak, I would expect them to have security teams who can backport fixes. In best case even upstream their backports.

It reminds me that I have a few pull requests waiting for backports that could be upstreamed:

• [flatpak-1.6.x] Backport CVE-2021-21261, CVE-2021-21381 and CVE-2021-41133 fixes #4537
• [flatpak-1.10.x] Fixes for coverity warnings #4924
• [flatpak-1.10.x] app: Use autocleanup for FlatpakTablePrinter #4925
• [flatpak-1.10.x] revokefs: Use the right variable name in an error message #4926
• [flatpak-1.10.x] dir: Avoid a crash when looking up summary for a ref without an arch #4927
• [flatpak-1.10.x] Fix cosmetic issues detected by scan-build #4931

There's also this one, but I forgot that it's waiting for me: #4932