[Development] Deprecation/removal model going into Qt 6

[Giuseppe D'Angelo]

Hi,

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 
multiple steps:

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 
account.

* 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...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190531/c2790ee9/attachment.bin>