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

[Ivan Solovev]

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.solovev at 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-bounces at qt-project.org> on behalf of Marc Mutz via Development <development at qt-project.org>
Sent: Tuesday, January 14, 2025 7:20 AM
To: development at 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.mutz at 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 at qt-project.org
https://lists.qt-project.org/listinfo/development