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.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: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
