Re: Re: Decommissioning Qt 5 CI
Ben Cooksley <[email protected]> Fri, 31 Jul 2026 06:53:47 +1200
| Newsgroups | gmane.comp.kde.devel.general |
|---|---|
| Message-ID | <CA+XidOFFEFPE8jHJg9Lf47HwK8iTWHj7CqyTXV8h8FXiKkR6cQ@mail.gmail.com> |
--0000000000004ecf7e0657d89844 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 31, 2026 at 3:47=E2=80=AFAM David Redondo <[email protected]= > wrote: > Am Donnerstag, 30. Juli 2026, 17:22 schrieb Ingo Kl=C3=B6cker: > > On Dienstag, 28. Juli 2026 23:36:20 Mitteleurop=C3=A4ische Sommerzeit A= lbert > Astals > > Cid wrote: > > > El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d=E2=80=99est= iu > d=E2=80=99Europa > > > 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 sto= p > > > > 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-qt5= 15 > > > > 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 --0000000000004ecf7e0657d89844 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transpare= nt">On Fri, Jul 31, 2026 at 3:47=E2=80=AFAM David Redondo <<a href=3D"ma= ilto:[email protected]">[email protected]</a>> wrote:</span></div>= <div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail= _quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204= ,204);padding-left:1ex">Am Donnerstag, 30. Juli 2026, 17:22 schrieb Ingo Kl= =C3=B6cker:<br> > On Dienstag, 28. Juli 2026 23:36:20 Mitteleurop=C3=A4ische Sommerzeit = Albert <br> Astals <br> > Cid wrote:<br> > > El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d=E2=80= =99estiu d=E2=80=99Europa<br> > > central), Nicolas Fella va escriure:<br> > > > That said, we have a number of (Plasma) components that we s= till build<br> > > > for Qt5 for (external) application compatibility (breeze,<br= > > > > plasma-integration, etc). So far we have not made a decision= to stop<br> > > > doing that, and I'd rather not lose CI for those. That d= oesn't mean we<br> > > > need Qt5 CI in the current form. Could we use a distribution= image with<br> > > > Qt and the few necessary libraries/frameworks baked in? That= would be a<br> > > > much smaller image and easier to maintain than the current s= use-qt515<br> > > > image.<br> > > <br> > > Does the code of those repos change in qt5 related areas?<br> > > <br> > > Trying to understand what we want CI for here:<br> > >=C2=A0 * Potentially new qt5 code builds with old qt5/gcc distros?= <br> > >=C2=A0 * Non changing qt5 code builds new gcc/stuff from distros?<= br> > <br> > Additionally to Albert's questions I don't understand why dist= ros that still <br> > need Qt 5 builds of breeze and plasma-integration cannot simply build = the <br> > latest released versions that support(ed) Qt 5. Why do they need the l= atest <br> > and greatest breeze and plasma-integration for the remaining Qt 5 apps= which <br> > probably haven't seen a release in years? Does plasma-integration = need to <br> > match the version of Plasma?<br> > <br> > Regards,<br> > Ingo<br> > <br> We did this with Plasma 5 and Qt 4 things.<br> For Plasma 6 we decided that we want applications to look and behave the sa= me <br> no matter if they use Qt 5 and Qt6. To the user Qt5 vs. Qt6 makes no differ= ence <br> and they would be confused or file a bug if some applications randomly look= and <br> behave differently.<br> For example single click vs. double click which was changed in Plasma 6.0<b= r> or breeze which received user visible changes since 6.0.<br></blockquote><d= iv><br></div><div>So the Plasma developers want to keep supporting Qt 5 for= essentially eternity and never drop support for it?</div><div><span style= =3D"background-color:transparent"><br></span></div><div><span style=3D"back= ground-color:transparent">At what point do you stop, or do you just keep co= ntinuing to maintain compatibility because one distribution doesn't wan= t to drop $unmaintainedQt5App?</span></div><div><br></div><div>Will Plasma = developers keep Qt 5 installed on their local machines and perform appropri= ate testing for that with the legacy, unported applications still using Qt = 5?</div><div>Just having CI compile something isn't a true test as to w= hether it works or not and risks silent bitrot taking place due to behaviou= r differences between Qt 5 and Qt 6.</div><div><span style=3D"background-co= lor:transparent">=C2=A0</span></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"> <br> Cheers,<br> David<br> <br></blockquote><div><br></div><div>Regards,</div><div>Ben=C2=A0</div></di= v></div> --0000000000004ecf7e0657d89844--