[Development] Deprecation/removal model going into Qt 6

[Giuseppe D'Angelo]

Il 31/05/19 15:24, Volker Hilsheimer ha scritto:
> Hey Guiseppe,

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

Thanks for confirming my reading.

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

To be honest, the real deal is 2). In this scenario that's the step 
which is absolutely necessary to migrate to Qt 6. (In the real world 
scenario, one also has to deal with other behaviour changes, e.g. the 
aforementioned QList).

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

Sorry, let me be more accurate: by scriptable I also mean that there is 
no behavior changes. E.g. rename QList to Qt5List, without changing 
anything; porting is running a search&replace.

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

I don't have a proposal because I didn't spend time researching it. It 
felt like a massive exercise for little gain.

As I said I don't think that there will be a "one size fits all" 
solution, but API by API decisions; one has to try to do some of the 
changes, find ways to preserve API compatibility, and then eventually 
come up with guidelines / coding policies employing various techniques 
(inline namespaces, Qt5Support library, build system tweaks, etc.). This 
makes the task non trivial in size.

Also, I can only speak comfortably regarding the planned changes to 
QtCore.  At this point in time I know very little about the planned 
changes to QtGui, QML, Qt Quick, etc.; I cannot therefore come up with a 
comprehensive proposal.

<evil>

Finally, the decision of the hard break seems to have already been made; 
instead of spending my energies trying to come up with a mitigation 
plan, I could instead spend them elsewhere, e.g.:

* under the blanket cover of the "API breaks are OK in Qt 6", implement 
(some of) the things proposed in the other thread;

* write porting documentation, augment our porting plugins for 
compilers, our porting scripts suite, and so on (we're the #1 
independent consultancy for Qt, after all, and we do sell migrations).

</evil>


Thanks,
-- 
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: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190602/101cecc0/attachment.bin>