Decommissioning Qt 5 CI

David Redondo kde at david-redondo.de
Thu Jul 30 16:47:24 BST 2026


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.

Cheers,
David






More information about the kde-devel mailing list