> On 16 Jan 2019, at 10:08, Lars Knoll <lars.kn...@qt.io> wrote: > >> On 16 Jan 2019, at 09:47, Alex Blasche <alexander.blas...@qt.io> wrote: >> >>> From: Development <development-boun...@qt-project.org> on behalf of Lars >>> Knoll <lars.kn...@qt.io> >>> For now I’d like to limit this to qtbase, as that’s where pretty much all >>> Qt 6 related work happens, >>> and we need to do some work on the CI side to prepare the other modules for >>> Qt 6 related work >>> (Frederik will post details in a separate mail). >> >> Lars, could you please elaborate on this point? What does for now mean? What >> time frames are we talking about? >> Where does the assumption come from that all Qt 6 related work happens in >> qtbase only? >> >> I think I know what you might want to say but the above is too absolutely >> phrased and I want the statement clear and not fuzzy. Hence please elaborate. > > Currently, most of the efforts towards Qt 6 are preparations that are > happening in qtbase, so I believe we need the branch there now, so at least > some work start. > > For other modules, we will of course also need Qt 6 related branches as soon > as possible. But we do need to get the model on how to work in those with > respect to our CI in order first. The problem here is that our CI makes > working with source incompatible changes difficult between repositories. I > believe we’ll need to fix that before we can create qt6 branches for the > other repositories that compile and test against qtbase/qt6. > > Of course you could create a wip branch for other repositories now as well to > do Qt 6 related work that doesn’t require Qt6 related changes from qtbase.
I thought the plan before was to use version checks like #if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0) And so we have some of those. But it hasn’t been clear how to test them (or at least I didn’t take the time to figure it out). I would have liked to start doing builds like that regularly a couple years ago. We should have had a configure option for that already, as soon as we started doing that, IMO. But as soon as qtbase has a qt6 branch, configure in that branch will set that version, and then we can build other modules and test that conditional Qt 6 functionality, right? As soon as we have a qt6 branch for a given module, should we start removing the version checks and the Qt5-specific code? Or will we put that off until nearer the Qt 6 release? Which way is going to make merges easier? _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
