Re: Decommissioning Qt 5 CI
Albert Astals Cid <[email protected]> Tue, 28 Jul 2026 23:36:20 +0200
| Newsgroups | gmane.comp.kde.devel.plasma,gmane.comp.kde.devel.core,gmane.comp.kde.devel.general,gmane.comp.kde.releases |
|---|---|
| Message-ID | <[email protected]> |
El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d=E2=80=99estiu d= =E2=80=99Europa=20 central), Nicolas Fella va escriure: > On 28/07/2026 12:52, Ben Cooksley wrote: > > Hi all, > >=20 > > For some time now Qt 5 has been in extended maintenance / support, > > which Iif my understanding is correct has now come to an end. > >=20 > > 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. > >=20 > > 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. > >=20 > > Please let me know if there are any objections. >=20 > Hi, >=20 > 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. >=20 > 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? Cheers, Albert >=20 > Cheers >=20 > Nico