Decommissioning Qt 5 CI
Ben Cooksley
bcooksley at kde.org
Tue Jul 28 12:39:57 BST 2026
On Tue, Jul 28, 2026 at 11:21 PM Nicolas Fella <nicolas.fella at gmx.de> wrote:
> 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.
>
Correct.
>
> 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
>From my understanding distributions are stripping Qt 5 support out fairly
quickly, so i'd be inclined to end support for Qt 5 in those Plasma
components, and for distributions still shipping Qt 5 ask them to keep
building the last release of those components that supported Qt 5.
>
> 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.
>
CI images even with things baked in have a degree of cost associated with
them as distributions drop packages / change package names (ignoring the
storage requirements for those images).
Do those components have promises not to use fancy new C++ features, etc
that often require modern, up to date compilers that wouldn't necessarily
be featured in a stable distribution?
>
> Cheers
>
> Nico
>
>
Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20260728/ce7729b7/attachment.htm>
More information about the release-team
mailing list