nicolas.fella at gmx.de
Thu Sep 8 01:07:05 CEST 2022
Am 07.09.22 um 08:45 schrieb Kevin Kofler via Development:
> Alex Blasche wrote:
>> 2.) An alternative might be to make this change in one go for Qt 7. We
>> would keep Qt 6.x on the status quo but start adding compatible
>> replacement APi with an absolute change at 7.0 (ifdefs or typedefs come to
>> mind). Users would only be burdened one time (though it being one BIG time
>> effort). Such a change would be much simpler in Qt headers.
> It scares me that a Qt 7 is already being planned or discussed at all,
> considering that your major consumers such as KDE Plasma are not even ported
> to Qt 6 yet! (Note that I am talking about *consumers* here, not only about
> (paying) customers. The former includes FOSS projects such as KDE.)
> Those major/BIC releases need to happen a lot less frequently, or ideally,
> stop entirely. At least if you want your consumers to keep up (and you
> clearly do or you would not have restricted access to Qt 5.15 LTS).
> You should plan for Qt 6.x releases (rather than 7.x) for at least 10 more
> years, if not indefinitely.
The fact that KDE does not use Qt6 yet has rather little to do with the
quality of Qt6. The main reason is that we want to polish our own APIs
more before introducing a new major version of them, which will be based
on Qt6. If you are actually interested about what KDE thinks about Qt6
you can find my thoughts at https://www.youtube.com/watch?v=nBzYuZIX1iY.
Please do not use KDE for your arguments and demands without actually
checking with relevant people whether your assumptions are correct.
More information about the Development