On Wed, Sep 7, 2022, at 08:45, Kevin Kofler via Development wrote: > 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.
I second this, considering the breakages in APIs and behavior, and bugs introduced, in Qt 6, I feel discussions about Qt 7 send a very poor signal. Porting to Qt 6 is a huge and costly effort. With so much care being made not to break BC, I would hope more care would be taken to preserve behavioral (QVariant/QMetaType) and API compatibility. I hope KDE not using Qt 6 yet sends a message taken seriously on the Qt side. Stay on Qt 6 for a long time guys. Andreas _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
