Decommissioning Qt 5 CI

[Ben Cooksley]

On Wed, Jul 29, 2026 at 10:07 PM Nicolas Fella <nicolas.fella at gmx.de> wrote:

> 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.
>

Seems that some distributions are actually going ahead with full removal or
have already done so which matches up with the view that it is well and
truly dead?

This feels like quite a bit of effort being justified for a few small
pieces of software that will only be used by a small number of applications
(as most have ported) that are themselves legacy and likely to have
maintenance issues (because otherwise they'd be ported already).

In my view, the expense of maintaining Qt 5 support for that very small
handful of Plasma projects is not particularly well justified.


>
> 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.
>
>
Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20260730/8206ef8a/attachment.htm>