> From: Edward Welbourne
[...]
> We currently have a delay between
> * When the replacement API is available and deprecation markers are in
> place and
> * When the deprecation kicks in
I vividly remember the handful of APIs that were deprecated in 5.15 and removed
in 6.0 (with replacement API
For reference, here are Jan Arve's notes from the QtCS 2024 session:
https://wiki.qt.io/QtCS2024_Deprecate
On Tuesday 14 January 2025 08:46:40 Pacific Standard Time Jaroslaw Kobus:
2. APIs that we want to only deprecate. All agrees on it, no one
complains.
Thiago Macieira (14 January 20
Let me add a preface that I probably should have added initially:
Understand that I am, of course, aware of the maintenance cost aspect of
not removing deprecated APIs, esp. modules. I am also aware that, as a
commercial entity, TQtC is free to set their priorities as they wish and
see fit. But
Hear hear.
I would also bring to the table the removals from QtQuick API. The
QtQuick.Extras was removed in Qt6. The missing CircularGauge (which is
non-trivial to implement or port) has prevented me to migrate to Qt6.
With modern C++, the value of Qt is the multiplatfrom GUI (and as a
profes
If I may add a user's perspective to the discussion.
I know gift season is over, but here is what I (as a user) would ideally get:
1) Things get deprecated, including clear communicating when they are planned
to be removed (e.g. "to be removed in Qt 7" or "to be removed in Qt 8")
2) There is alway
