Hi. I tried to start a similar discussion in October [0], but there was no real conclusion apart from "let's decide on a case-by-case basis".
My idea was that we can at least use the new to-be-removed approach on the APIs that we consider wrong or dangerous. But the reality is that we cannot agree even on that (consider the discussions about QScopedPointer::take() in [1]). It all makes me think that we really need to agree on some policy. > So, to me, it follows that > we need to actually switch the default and make removal² the exception, > to be used only with very good reasons, not just "it's deprecated". That's how it should work, yes. IIRC, we already agreed that we wouldn't automatically disable all the deprecated APIs when switching to Qt 7. And that's exactly why I introduced the new macro for deprecation-and-removal. > on major version change, deprecated API is being inlined, if that is > feasible, and we fix BC issues +1 to that > but major versions are no longer an SC break point I don't think that it's a good idea. We need to allow SC breaks at some point if we want to have a better API and/or design. That does not mean that we should blindly break everything for no reason, of course. > qt5compat stays in Qt 7 I don't think that it makes sense. Keeping the compatibility module for the lifetime of one major release should be enough. We need to identify the most important parts of it (e.g. the text codecs that people are still missing in Qt 6), and implement them in Qt 6 (or Qt 7). But I don't think that it makes sense to keep e.g. QStringRef forever. People should just use QStringView instead. > modules that are deprecated (at least from now on, QtDatavis3D, > QtCharts, I'm looking at you) continue to be available (and > maintained) in Qt 7. +1 to that. I do not think that we would be able to simply drop these modules from Qt 7. Best regards, Ivan [0]: https://lists.qt-project.org/pipermail/development/2024-October/045820.html [1]: https://codereview.qt-project.org/c/qt/qtbase/+/599356/comment/4a6f8bc6_308fad4f/ ------------------------------ Ivan Solovev Senior Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 12489 Berlin, Germany ivan.solo...@qt.io www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ________________________________________ From: Development <development-boun...@qt-project.org> on behalf of Marc Mutz via Development <development@qt-project.org> Sent: Tuesday, January 14, 2025 7:20 AM To: development@qt-project.org Subject: [Development] QtCS 2024 session on deprecations: what did we actually agree on? Hi. At QtCS last year, we had a session on deprecations. From the summary at https://wiki.qt.io/QtCS2024_Deprecate, we've done (2)¹, but it seems like we have not come to grips with what (1) (deprecation is not removal) actually means. As far as I am concerned, it cannot mean "continue as before", because that doesn't change anything for our users. So, to me, it follows that we need to actually switch the default and make removal² the exception, to be used only with very good reasons, not just "it's deprecated". That means, among other things: - on major version change, deprecated API is being inlined, if that is feasible, and we fix BC issues, but major versions are no longer an SC break point - qt5compat stays in Qt 7 - modules that are deprecated (at least from now on, QtDatavis3D, QtCharts, I'm looking at you) continue to be available (and maintained) in Qt 7. Are we willing to do that? Personally speaking, I'm not willing to put in the effort in QtCore if all around me whole leaf modules are dropped, sometimes without replacement (e.g. QtXmlPatterns). So, what did we actually decide in Würzburg? Thanks, Marc ¹ https://codereview.qt-project.org/c/qt/qtbase/+/599356 ² Not in the REMOVED_SINCE sense, as that just removes deprecated API/ABI at _user_ discretion, but in the QT_VERSION < 7 or actually, physically, delete the code. -- 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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
