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
