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
