[Development] Deprecation/removal model going into Qt 6

[André Pönitz]

On Fri, May 31, 2019 at 02:50:45PM +0200, Giuseppe D'Angelo via Development wrote:
> 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 was never *my* plan, and the plan listed here has exactly the
problems you mentioned.

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

I think the compromise is API-by-API deprecation, with a grace period
for each one (>= 1 LTS cycle) between the availability of a serious
alternative for that API and the deprectation marking of the old
version. And with "serious" I mean something not contested, i.e. nothing
based on "there's a boost library doing something similar" or "I do
not use this API, so nobody else should use it either".

In all other setups it is practically impossible to use deprecation
warnings as errors.

> Anyhow, flame away.

I see no reason for flames here, I fully agree with what you wrote.

If there's no transitional phase where a codebase can be reasonably
easy be compiled with Qt 5 and Qt 6 we'll end up in a situation where
staying with Qt 5 for eternity will be the prefered solution for some.

We need to take into account that a lot of code is still written in
a way that only schedules resources for creation, but not for active
maintenance. Usually some life support happens "for free", but real
porting cannot be done in such circumstances.

Andre'