Decommissioning Qt 5 CI

[Nicolas Fella]

On 29/07/2026 12:00, Ben Cooksley wrote:
> On Wed, Jul 29, 2026 at 7:31 PM David Redondo <kde at david-redondo.de> 
> wrote:
>
>     Am Dienstag, 28. Juli 2026, 23:36 schrieb Albert Astals Cid:
>     > El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d’estiu
>     d’Europa
>     > central), Nicolas Fella va escriure:
>     > > On 28/07/2026 12:52, Ben Cooksley wrote:
>     > > > Hi all,
>     > > >
>     > > > For some time now Qt 5 has been in extended maintenance /
>     support,
>     > > > which Iif my understanding is correct has now come to an end.
>     > > >
>     > > > Accordingly, given that all of our applications have now had a
>     > > > substantial amount of time to migrate, and plenty of notice
>     that CI
>     > > > would be withdrawn eventually, i'd like to proceed with
>     withdrawing CI
>     > > > support for Qt 5.
>     > > >
>     > > > This will free up valuable space on the CI nodes and allow us to
>     > > > remove an image that is under very minimal, if any, maintenance.
>     > > >
>     > > > Please let me know if there are any objections.
>     > >
>     > > Hi,
>     > >
>     > > for applications I agree to drop Qt5 CI. The few usages that
>     are left
>     > > either already have Qt6 CI, or are more or less dead projects.
>     > >
>     > > That said, we have a number of (Plasma) components that we
>     still build
>     > > for Qt5 for (external) application compatibility (breeze,
>     > > plasma-integration, etc). So far we have not made a decision
>     to stop
>     > > doing that, and I'd rather not lose CI for those. That doesn't
>     mean we
>     > > need Qt5 CI in the current form. Could we use a distribution
>     image with
>     > > Qt and the few necessary libraries/frameworks baked in? That
>     would be a
>     > > much smaller image and easier to maintain than the current
>     suse-qt515
>     > > image.
>     >
>     > Does the code of those repos change in qt5 related areas?
>     >
>     > Trying to understand what we want CI for here:
>     >  * Potentially new qt5 code builds with old qt5/gcc distros?
>     >  * Non changing qt5 code builds new gcc/stuff from distros?
>     >
>
>     breeze, oxygen and plasma-integration is
>     * new qt5 code builds on current distros
>     it changes as the qt6 code changes. The goal is that qt5 and qt6
>     applications
>     look and feel the same.
>     For breeze and oxygen the same code base is compiled twice, once
>     with qt6 and once with qt5.
>     plasma-integration has copies of the code for qt5 and qt6 because
>     the ifdef'ery became a bit too much.
>
>     Non changing qt5 code that I can think of is kwayland-integration
>     which is an implementation detail of kf5/plasma5
>     but we provide in plasma6 to keep kf5 apps working.
>
>
> Not a huge fan of the idea of keeping Qt 5 around in any form at all 
> to be honest.
>
> Do the Plasma developers have a view as to when this support will be 
> dropped given that distributions are rapidly dropping support for Qt 5?

Looking at 
https://mail.kde.org/pipermail/distributions/2026-June/001695.html we 
are not quite there yet when it comes to getting rid of Qt5 entirely.


> This feels like something that is going to require work to implement 
> and will be dropped in 6 months or so given the speed distros are 
> moving at, and if that is the case my preference would be to just move 
> up the end of support and do it all now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20260729/9f84dd65/attachment.htm>