[Development] Deprecation/removal model going into Qt 6

[Volker Hilsheimer]

Hey Guiseppe,

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


That is my understanding as well. Yes, 5.15 will be an LTS, and assumed to be the last feature release in Qt 5.


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


With the assumption being that “port to Qt 5.x latest” is not a huge deal, but I guess there are cases where it is not trivial either.

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

Thinking about all cases and situations is usually hard, often impossible; that fact doesn’t change by moving to a different way of deprecating and removing stuff. Some people will have used things in a way that nobody anticipated, and they will have less fun than others.


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


Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with three years maintenance. We are not expecting lots of people to jump on Qt 6.0 anyway (because .0, and not an LTS release anyway), so when an API was marked as deprecated makes perhaps not that much difference “in real time”.


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


Even a scriptable migration path might only give you compilable code; the nuanced behavior of the new class you migtated to might not be identical to what your code assumes.


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



Any proposal for such a “somehow” would certainly be appreciated. And source breakage is a much smaller problem than “no source breakage, but behavior is different”.

The overall goal here is to make sure that we don’t have to carry poorly designed architecture or APIs around with us throughout the Qt 6 series, and as long as we care about binary and source compatibility within a major series, doing what we can for Qt 6.0 (and doing it right) is the only option we have.

Perhaps we can care less about those compatilbiity promises; I personally think the "big bang every 7 years” is not giving us nearly as much as it costs; a continuous flow of carefully managed changes to either would perhaps make it rather easier for developers to follow along, and remove those big, painful porting headaches (unless you didn’t follow the Qt releases, in which case it’s just as bad as it is today).



Volker