On Fri, Jul 31, 2026 at 9:15 PM David Redondo <[email protected]> wrote:
> Am Donnerstag, 30. Juli 2026, 20:53 schrieb Ben Cooksley: > > On Fri, Jul 31, 2026 at 3:47 AM David Redondo <[email protected]> > wrote: > > > [Snip] > > > > 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? > > (readding dropped lists) > > I dont't know the concrete point in time but given that there are some > big > applications on still on Qt5 I would say it's too early now. > Please quantify that and list the applications you consider "big" that need to have ported before this can be abandoned. > > Btw Plasma 5 dropped support of Qt4 builds of breeze and oxygen in 2020 > with > 5.18, see > https://mail.kde.org/pipermail/plasma-devel/2020-January/108585.html > > I don't think we need an image provided by sysadmin and build kf5 on our CI > infra. Couldn't we just download a image of $LTS distro like okular does? > > https://invent.kde.org/graphics/okular/-/blob/master/.gitlab-ci.yml? > ref_type=heads#L24 > <https://invent.kde.org/graphics/okular/-/blob/master/.gitlab-ci.yml?ref_type=heads#L24> Depends on the number of times your job runs. Doing jobs that way is expensive because everytime the job runs it re-fetches every single dependency from distribution archives and installs them in the container before it even starts building. > > > > 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 > > Regards, Ben
