RFC: Switching to min Qt version 5.14 for KF on December 14th

Friedrich W. H. Kossebau kossebau at kde.org
Tue Dec 8 13:50:02 GMT 2020


No time left to cut the reply short right now, please bear with me...

Am Montag, 7. Dezember 2020, 16:34:16 CET schrieb Volker Krause:
> On Sonntag, 6. Dezember 2020 14:20:47 CET Friedrich W. H. Kossebau wrote:
> > you might have seen I asked* whether anyone knows a real world requirement
> > to stick with Qt 5.13 as new current minimum required Qt version for
> > current KF releases. So far no-one had to report a reason to support Qt >=
> > 5.13 instead of only Qt >= 5.14 now.
> > * E.g.
> > https://mail.kde.org/pipermail/distributions/2020-December/000894.html
> > 
> > So hereby I propose to switch for KF 5.78 to Qt 5.14 as minimum version,
> > and change the KF dependencies policy text* to this:
> > * https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements
> > 
> > "
> > With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5
> > versions would be released. Then adapt to actual real world usage of a
> > given Qt version:
> > * Qt 5.13 will be the minimum required version 6 months after Qt 5.15,
> > i.e.
> > on 26 Nov 2020
> > * Qt 5.14 would be the minimum required version 12 months after Qt 5.15,
> > i.e. on 26 May 2021. With no-one known to stick with Qt 5.13, the date is
> > moved to earlier mid-December 2020.
> > * Qt 5.15 LTS will be the minimum required version 18 months after its
> > release, i.e. on 26 Nov 2021
> > "
> 
> Thanks! I'm generally in favor of an accelerated path to Qt 5.15 as the
> minimum dependency in the light of the upcoming Qt 6 transition. The
> proposed approach only addresses half of the problem though, we'll end up
> with the same discussion in a few month again I fear. Would it therefore
> make sense to cover this as well now, so people can plan ahead?

Revisiting the date of going to Qt 5.15 as min. dependency now and then to 
align to the real world makes sense to me.
Ideally in a separate thread though, please :)
As IMHO the decisions are related, but would not depend on each other (other 
than 5.14 < 5.15).

That discussion might also want to consider how much we are able to set the 
date and have distributions follow us, or how much we need to adjust to the 
world they create and in which the KF contributors and consumers live.

BTW, IMHO we should also bump the min version at the begin of the KF 
development cycle, for the usual reasons, not just on the very dates, which 
have been close to tagging/branching in the KF schedules. We would rather use 
those dates as needles, and then bump at the begin of the cycle for the first 
version released after the needle. (at least I expect KF contributors to not 
also only after that date being able to use the newer minimum Qt version). 
(the current Qt 5.14 proposal's date December 14th is derived from the timeout 
of the RFC, otherwise I would have proposed the bump execution to happen 
around version bump time, i.e. once the previous release happened).

> One thing I haven't really seen addressed yet is Krita's concerns about
> newer Qt versions, how do we want to handle that?

Also no idea. My hope would be that in the assumed non-Qt-company patch 
collection the FLOSS world will create for Qt 5.15 (given there will be no 
further official Qt 5.15 releases, or where are we now?) someone also manages 
to do a fix for the QMdi on Windows regressions that popped up in Qt 5.13 (if 
I got the issue correctly). So Krita could use Qt 5.15 FLOSS fork with Windows 
and passed that hurdle. So far my bet on others resolving the issue outside KF 
spheres.
>From KF side we already screwed Krita with KF 5.77 now here. Going back to Qt 
5.12 as minimum dep for future KF versions... as much as I cheer Krita for the 
incredible awesome project it is, that would be a big price to pay by everyone 
else. Given Krita had forked some non-tier1 KF modules (for reasons I 
understand, and their product success confirms the decision) it also makes it 
harder for me to argue to have everyone sacrifice in the KF modules just for 
them by sticking to Qt 5.12 as min dep.
For now Krita is stuck with KF 5.76 as minimum KF version then for the Windows 
builds, and would need to backport patches for any important bug fixes. Given 
that current master has MIN_QT_VERSION 5.9.0 and MIN_FRAMEWORKS_VERSION 
5.44.0, building with not the latest KF modules on Windows might not be such a 
bummer, and perhaps those limits are not raised near KF 5.77 a lot until Krita 
considers Qt6 anyway?
(And did Wolthera explore the feasibility of Godot as UI toolkit as another 
approach to the problem? ;) )
But that is my uninformed view from the outside, Boud & fellows have to fill 
in here with their future plans and needs/desires/ideas.

Cheers
Friedrich




More information about the Kde-frameworks-devel mailing list