[Development] Deprecation/removal model going into Qt 6
giuseppe.dangelo at kdab.com
Fri May 31 14:50:45 CEST 2019
It seems to me that many emails in the earlier deprecation thread were
from users concerned by the problem of removal of functionality. This is
not an old story.
However, apart from the specifics of why deprecating a certain class /
what to replace it with / etc., there's a bigger thing that needs to be
clarified, which is: what is the deprecation/removal model going into Qt 6.
It is my understanding that the current plan is to:
* _remove_ from Qt 6.0 any API deprecated in Qt 5.x (for any x);
* in order to ease the migration from Qt 5, any API that is going to be
removed/changed in Qt 6.0 (for any reason) is also going to be
deprecated in Qt 5.latest (5.15 LTS, AFAIU).
I guess that the idea is that the port to Qt 6 can then happen in
1) port to Qt 5.latest;
2) (enable and) fix all deprecation warnings;
3) port to Qt 6.
If this is still the plan, I must say I am not a huge fan of it. It has
all the premises to be another Qt3->4 hit. Specifically:
* It assumes that any breaking change will happen in Qt 5 first,
signalled via deprecation macros, then Qt 6 will simply remove the
deprecated parts. As we're already seeing with e.g. QList, this is not
happening for all the possible cases, meaning the porting steps above
are incomplete and there will be some extra porting fallout to take into
* It does not let users move away at their own pace. Qt 6.0 will be
inaccessible for existing Qt 5 software until one has ported away from
every deprecated API. If we keep deprecating things (and add
replacements) up to 5.latest, then this also makes it complicated for
users to build libraries and components targeting both Qt 5 and 6.
Such libraries may end up to only be able to target Qt 5.latest and 6
together, without resorting to #ifdefs or similar machinery in their
code; the reason is that only 5.latest would have the required
replacement APIs for the ones deprecated in 5.latest / removed from 6.0.
* It does not make a distinction w.r.t. _when_ an API has been
deprecated. IMHO there is a difference between an API deprecated in 5.0
and one deprecated in 5.15; users had much more time to port away from
the former. Dropping them both on the floor in 6.0 seems very unfair to
me, again forcing users to tackle the deprecation _immediately_ if they
want to port to Qt 6.
* It does not make a distinction between APIs for which we have a
straightforward / immediate / scriptable (!) replacement, and APIs for
which we don't (yet we'd like to get rid of them). Keeping the latter
APIs as stable and supported in Qt 6.0 means keeping them since 7.0 and
then face have the same problem again. But simply dropping them means
pain for users.
Given all the work that went into adding deprecation macros during Qt 5
lifetime (even the multiple incantations of them), would it be possible
somehow to avoid most of the source breaks caused by removal of the
deprecated APIs? I know that it's easier said than done, as it would
require doing this on a API-by-API basis rather than turning a big
switch; but we could find some compromise somewhere.
Anyhow, flame away.
Thanks for reading,
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
More information about the Development