QT/KDE - Is it time to converge toward a consistent release cadence?

Project Discussion
,
1

KDE Plasma’s release schedule documentation says that a shift to a 6 month cadence will be considered once distributions ask them to consider it. Is it time to converge toward a consistent release cadence?

  • QT Community Edition: Minor releases every 6 months, maintained for approximately 12 months. For the first 6 months, the public download mirror [1] will get patch-release updates. For the second 6 months, security updates appear to continue to be published, but only in the form of patch files.

  • KDE Plasma 6: Minor releases every 4 months, maintained for just over 4 months (20 weeks). [2]

  • KDE Flatpak runtime: Minor releases every 6 months, maintained for approximately 13 months. [3]

  • Fedora: Major releases every 6 months, maintained for approximately 13 months, but KDE and QT are shipped as rolling releases.

Within that set of release schedules, most projects have adopted a 6 month cadence with a 12 or 13 month maintenance window.

I think that users, developers, and Fedora would all both benefit from converging toward a more consistent release schedule, but that requires several different changes.

First, KDE would need to adopt the 6 month release cadence. Their documentation suggests they will do this at some point, but they seem to be waiting for someone to ask them to do so. In Nov '24, they mentioned that they would defer that change until the list of significant known issues with Wayland was empty, but a year later they announced plans to remove support for X11 sessions in early '27… If the Wayland issues list isn’t a barrier to removing X11 session support, maybe it also isn’t a barrier to adjusting the release cadence.

Second, since QT security fixes after 6 months are shipped only as patch files and not as a release for QT, automated tracking of releases doesn’t fit well into the monitoring that we have today. That looks like it also affects the KDE Flatpak runtime. In the past, they have applied patches when I have asked them to do so, but they don’t appear to have any mechanism for monitoring the mirror for security patches. Both KDE and Fedora need monitoring if we were to converge on a stable release schedule.

Finally, and this may be a stretch, it would be nice if KDE would also provide patches for security flaws for the duration of the KDE Flatpak runtime maintenance window. Their release documentation says no LTS releases, but providing at least security patches to the Flatpak runtime and to Fedora would improve both the stability and security posture of both.

Converging on a consistent release schedule would improve the security posture of the KDE runtime on Flathub. It would also permit Fedora to stop rolling QT and KDE within the stable release, and to provide a runtime that is as stable as KDE’s runtime on Flathub. Fedora would no longer be required to rebuild everything that uses QT’s private interfaces in the middle of a release. In turn, it will be easier for developers to target the Fedora platform.

[1]: https://download.qt.io/official_releases/qt/6.9/

[2]: https://community.kde.org/Schedules/Plasma_6

[3]: https://community.kde.org/Policies/Flatpak_Runtime_Update_Policy

[4]: https://community.kde.org/Plasma/Wayland_Known_Significant_Issues

4 Likes
2

Maybe it is, but it won’t help your actual question since what you seem to care about is Qt, and Qt will continue to roll as necessary whether or not Plasma lifecycles change.

Not exactly. Qt feature releases are semi-annual, and as soon as the new one goes out, the old one is no longer maintained publicly. That includes security fixes. There are a few exceptions (QtWebEngine, mainly), but by and large, public availability of Qt stuff for a release ends as soon as the next release is out.

(Also, it’s Qt, not QT. It isn’t QuickTime!)

I have been the one driving this question every year since 2022. I am the one who proposed the 1-3-6 schedule (Monthly frameworks, quarterly Gear, Semi-annual Plasma) in the first place. The Wayland issue was only one factor. There are a number of other issues, not the least of which is that many developers prefer that KDE software is released more frequently in the first place.

This isn’t actually how it works. Everything stops after the next release is out.

This isn’t going to happen. KDE upstream stretched itself thin doing it for Qt 5.15 while they moved to Qt 6, and it was a difficult endeavor both technically and politically.

We are not going to stop rolling Qt for a variety of reasons. One of the important ones is that rolling Qt is the only way we get platform fixes that support all Qt-based applications. As an example, Wayland features and fixes almost always require rolling to a new Qt version. Application developers aren’t supposed to be using Qt private interfaces in the first place, those mainly exist for KDE and other desktops to integrate with the toolkit. Fortunately, there aren’t that many applications that do this in the first place.

Frankly, rolling Qt itself isn’t even that difficult or an issue for most application developers. The Fedora KDE SIG has been doing it this way for a very long time now and we’ve had decent results. And it has allowed us to also reinforce our value in the larger community when we contribute fixes to projects to handle when build-time interfaces change (e.g. CMake changes, header renames, etc.). The community feedback from users and developers largely is that they prefer us rolling this stack because it makes Fedora more valuable to them as a development platform for Qt-based projects. It is occasionally a little bumpy, but it has generally worked out on the balance of things.

It would be nice if it was less painful to do reverse dependency rebuilds, but this is not a problem specific to us, other stacks have it worse (Go needs this so that security fixes from the Go standard library propagate into applications. Rust needs it for crate fixes to make its way into applications). Someday we’ll get as good as openSUSE on this.

Finally, this is the wrong audience to bring this up. If you want to really discuss this, you have to come to Akademy. :slight_smile:

1 Like
3

I thought that was true, too, for a long time.

A while back, I asked the KDE Flatpak runtime maintainers to address a couple of CVEs in Qt 6.8, which they did, using patches from the Qt official releases site. Qt’s documentation lists patch releases that are not available to the public on that site, so it’s definitely true that they’re providing releases to paying customers that aren’t available to non-paying customers. But it does not seem to be true that “everything stops” when there’s a new minor release. For each release series that I’ve checked, there are security patches published on the public site after the release of a new minor series. And, to be clear, for each CVE that I have checked, there are security patches on Qt’s site.

As far as I can tell, it should be possible to ship a stable Qt, fully patched against known vulnerabilities, for one year. But right now neither Fedora nor KDE’s Flathub runtime are doing that. And I think that’s a flaw for both projects.

One of the reasons I’m bringing this up now and not next year is that we have a proposal open to allow some Fedora variants to effectively make Flathub their primary source of desktop applications. I don’t think that’s a good idea unless KDE starts patching CVEs in their runtime after the 6 month mark, which should be a simple step for them. Qt Group is publishing patches, but no one seems to be monitoring patches, only releases.

Separately, shipping a stable Qt in Fedora would give everyone the benefit of asynchronous work. With a rolling release, everything has to be coordinated to build, and test, and release simultaneously. If we shipped a stable Qt, we cut that out, and we also give Fedora Flatpaks the ability to select a Qt target, which is … the whole point of the stable release process.

rolling Qt is the only way we get platform fixes that support all Qt-based applications. As an example, Wayland features and fixes almost always require rolling to a new Qt version

If we ship a stable Qt, users who want the platform fixes in a new Qt release can upgrade to a new Fedora release. That’s the purpose of the rapid release.

Developers who need an old Qt release for compatibility reasons can continue to use the old Fedora release (e.g., via a Flatpak that uses the previous release’s base layer). That’s the purpose of the stable release process.

KDE’s Flatpak runtime on Flathub serves both of those needs, using a stable release with a rapid cadence. (Though they need to track security patches!) Fedora only serves one of those audiences, today. I think we should consider how we can serve both.