qt/qtbase now has a branch wip/qt6. On 15.2.2019 10.03, Lars Knoll wrote: > 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 > > > _______________________________________________ > Gerrit-admin mailing list > gerrit-ad...@qt-project.org > https://lists.qt-project.org/listinfo/gerrit-admin >
-- --- Kari Oikarinen Senior Software Engineer The Qt Company Elektroniikkatie 13 90590, Oulu, Finland kari.oikari...@qt.io +358 50 5281010 http://qt.io --- _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development