[Development] QtCS 2024 session on deprecations: what did we actually agree on?

[apoenitz]

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'