On Tue, Jan 14, 2025 at 06:20:32AM +0000, Marc Mutz via Development wrote: > 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. I seem to remember that we decided that the decision to remove something will be independent from the decision to deprecate it. I don't remember a fixed default, my assumption is there is none, and I also think there doesn't need to be one. For me, it would make a lot of sense to do all the to-drop-or-not-to-drop discussions more or less in one go at the same time a few months before the major version change. As such an event would probably draw some attention, this gives us a chance to get some kind of (more) uniform judgement involving roughly the same participants at roughly the same time. This would nicely address one of the issues I had with the 5.x deprecations (plus resulting automatic removal in the end) which trickled in over a period of three(?) years, done by (often very few) different people with diverging directions that led in the end to a rather inconsistent distributed discussions and results. Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
