Let’s also conclude this thread. Majority consensus was that we need a branch and most votes went towards wip/qt6. So let’s use that for Qt 6 related work and create the required branch.
The following rules apply: * We CI test the branch on (at least) a reduced set of platforms/compilers. Minimum is one Windows/Linux/macOS platform. * dev gets merged into wip/qt6 on a regular basis * Don’t remove any functions from wip/qt6 unless they are marked as deprecated in dev or else you have discussed it on the mailing list and gotten maintainer approval for the removal * Do not break source compatibility without maintainer approval * Breaking binary compatibility is ok * Breaking internal API is in principle ok, but it’s the responsibility of the one doing the changes to help all other modules that are using that API to get ported. Be careful with those changes until we get the new module testing strategy implemented (see my other email on the Qt modules thread) Gerrit admins, can you create the branch for qtbase? If others maintainers want a wip/qt6 branch for their repositories, please create those as well. Let’s also hope that we now get the now sha1 pinning approach for module testing quickly to make handling of API changes across repo boundaries simpler. Cheers, Lars On 16 Jan 2019, at 14:28, Shawn Rutledge <shawn.rutle...@qt.io<mailto:shawn.rutle...@qt.io>> wrote: On 16 Jan 2019, at 10:08, Lars Knoll <lars.kn...@qt.io<mailto:lars.kn...@qt.io>> wrote: On 16 Jan 2019, at 09:47, Alex Blasche <alexander.blas...@qt.io<mailto:alexander.blas...@qt.io>> wrote: From: Development <development-boun...@qt-project.org<mailto:development-boun...@qt-project.org>> on behalf of Lars Knoll <lars.kn...@qt.io<mailto: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<mailto:Development@qt-project.org> https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
