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

[Volker Hilsheimer]

We decided in Würzburg that deprecation doesn’t imply removal in the next major version, and that a new macro (as added by Ivan) gives us the ability to make our intentions explicit at time of deprecation.

We might learn things between time of deprecation and the next major release that change our mind, in both ways. And we have 8 minor release where things got deprecated that we might want to remove in Qt 7, even though they were not deprecated using the new macro yet.

None of this implies that “Qt 7 will be source compatible with Qt 6”, or results in the automatism that Qt5Compat (or QtCharts, DataViz3D) continue to be included and maintained in Qt 7. Some things will stay, some won’t. We now have more ways to express (and allow a reviewer to confirm) which tradeoff we think is the right one, based on what we know right now.

Volker


> On 14 Jan 2025, at 10:10, Ivan Solovev via Development <development at qt-project.org> wrote:
> 
> 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
> -- 
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development