Decommissioning Qt 5 CI

[Ben Cooksley]

On Fri, Jul 31, 2026 at 3:47 AM David Redondo <kde at david-redondo.de> wrote:

> Am Donnerstag, 30. Juli 2026, 17:22 schrieb Ingo Klöcker:
> > On Dienstag, 28. Juli 2026 23:36:20 Mitteleuropäische Sommerzeit Albert
> Astals
> > Cid wrote:
> > > El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d’estiu
> d’Europa
> > > central), Nicolas Fella va escriure:
> > > > 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?
> >
> > Additionally to Albert's questions I don't understand why distros that
> still
> > need Qt 5 builds of breeze and plasma-integration cannot simply build
> the
> > latest released versions that support(ed) Qt 5. Why do they need the
> latest
> > and greatest breeze and plasma-integration for the remaining Qt 5 apps
> which
> > probably haven't seen a release in years? Does plasma-integration need
> to
> > match the version of Plasma?
> >
> > Regards,
> > Ingo
> >
> We did this with Plasma 5 and Qt 4 things.
> For Plasma 6 we decided that we want applications to look and behave the
> same
> no matter if they use Qt 5 and Qt6. To the user Qt5 vs. Qt6 makes no
> difference
> and they would be confused or file a bug if some applications randomly
> look and
> behave differently.
> For example single click vs. double click which was changed in Plasma 6.0
> or breeze which received user visible changes since 6.0.
>

So the Plasma developers want to keep supporting Qt 5 for essentially
eternity and never drop support for it?

At what point do you stop, or do you just keep continuing to maintain
compatibility because one distribution doesn't want to drop
$unmaintainedQt5App?

Will Plasma developers keep Qt 5 installed on their local machines and
perform appropriate testing for that with the legacy, unported applications
still using Qt 5?
Just having CI compile something isn't a true test as to whether it works
or not and risks silent bitrot taking place due to behaviour differences
between Qt 5 and Qt 6.


>
> Cheers,
> David
>
>
Regards,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20260731/cdb4a956/attachment.htm>