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.dang...@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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
