[Development] QtCS 2024 session on deprecations: what did we actually agree on?
apoenitz
apoenitz at t-online.de
Tue Jan 14 19:24:03 CET 2025
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'
More information about the Development
mailing list