On 14.01.25 14:50, Volker Hilsheimer wrote: > None of this implies that “Qt 7 will be source compatible with Qt 6”, or > results in the automatism that Qt5Compat (or QtCharts, DataViz3D) > continue to be included and maintained in Qt 7. Some things will stay, > some won’t. We now have more ways to express (and allow a reviewer to > confirm) which tradeoff we think is the right one, based on what we know > right now.
Forgive me, but that sounds quite a bit like the status quo. AFAICT, this whole issue came up because of two things: First, that projects insist on compiling with deprecation warnings enabled, but OTOH don't want to port away from deprecated APIs. The answer here is: if you don't want to port away from deprecated APIs, then don't enable deprecation warnings. Let us do our job deprecating APIs that we think new code should no longer use and as compensation, we promise that removal of deprecated API is the exception, and no longer the rule. Second, that we lose users with every major release. I don't know why, but I guess porting (either away from removed Qt APIs or away from now-unsupported tool-chains) is the reason for the vast majority of such "stuck in the past" projects. For both of these angles, the solution, from a user pov, is to _not_ remove APIs. If we can't commit, as a project, to a _substantial_ reduction of known-to-be-removed APIs, then why do we make a distinction at all? Users are not helped if 5% of APIs now survive that would have been slashed before. Users are helped if 95% of APIs stay, though. Can we clearly commit (from the project (and TQtC)) that the default is to _not_ remove. Including, but not limited to, the case where there is no 98/99% replacement. I'd go so far as to require to demonstrate an actual benefit for the _user_ from the removal. Some random examples that came up in water cooler talks: As removal candidate, Q5ThreadPool::cancel() comes to mind. That API was impossible to use correctly, and we quickly provided a working replacement (tryCancel()). Today, QSqlQuery's copy ctor came up as a removal candidate. Apparently, it, too, cannot be used correctly, because the underlying driver state can't actually be copied, and the copy ctor could only move. These are the only two that I can ever remember that were worth removing for the user's sake. I actually thought qsnprintf() was one, too, but then I considered an Android-only app that happily uses qsnprintf("%ls", qUtf16Printable(string)), whose port to std::snprintf() would be non-trivial. So I no longer consider even qsnprintf() to be a removal candidate. About Qt5Compat: there's still no replacement for QTextCodec, and I don't understand why it was ever moved out of QtCore. As a consequence, the first few Qt 6 releases weren't able to parse XML files with shift-jis encoding, a Qt 5 regression, still unfixed, except for libicu builds. Ditto QStringRef. We broke QStringRef -> QStringView conversion in the process of ripping QStringRef out of QtCore, and we left the XML classes with a minimal reimplementation of QStringRef that shares no code with the latter. Even QRegExp porting isn't trivial: QRegularExpression doesn't cache the compiled pattern, but QRegExp did, so you can get quite nasty performance degradation if you keep re-constructing the same QRegularExpression in a tight loop, while QRegExp would "behave". Summary: I see no reason, from a user perspective, to remove qt5support from Qt 7. Maybe we can make more fine-grained libraries libQTextCodec, libQRegExp, libQStringRef instead of using the "Qt N Compat" moniker and artificially binding them together. Like QT_NO_X instead of QT_DEPRECATED_V_X, that lets users tackle deprecated APIs at their own pace, in their own order, without being hit by these walls of changes with every Qt version. Something we ourselves have recently gotten a dose of when we tried to bump the QT_VERSION to 0x061000... -- Do unto others as you would have done to you. Thanks, Marc -- Marc Mutz <marc.m...@qt.io> (he/his) Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development