[Development] Deprecation/removal model going into Qt 6

[Lars Knoll]

Going back to the beginning of the thread.

> On 31 May 2019, at 14:50, Giuseppe D'Angelo via Development <development at qt-project.org> wrote:
> 
> 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:

Why do you think so? The plan above is actually stricter than what we did when moving from Qt 4 to Qt 5 (where (2) was only partially done).

So I believe that the plan above should not make it harder to move from 5 to 6 than the Qt4->5 move. Unless we go completely crazy with deprecations in 5.15 of course, but that’s something we should be careful about.

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

Removing deprecated functionality always forces the users hands. But at some point it has to be done, or we can never drop anything.

And btw, I’m not a fan of simply removing/deprecating tons of things without good reason (so I’m opposed to many of the things Marc brought up in the deprecation thread he initiated).
> 
> 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.

We can consider a staged approach, but there might be some cases, where we need to do a hard cut to get rid of some very heavy luggage for Qt. Where it doesn’t hurt us as much, deprecating and keeping it around in 6.0 is something we could discuss.
> 
> * 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.

As a general rule, we shouldn’t drop something where we do not have a replacement available. But there might be exceptions (XMLPatterns come to my mind).

Cheers,
Lars

> 
> 
> 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
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development