Thanks! Lars
> On 18 Feb 2019, at 09:03, Kari Oikarinen <kari.oikari...@qt.io> wrote: > > 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
