[Development] [Gerrit-admin] Branch for Qt 6

[Lars Knoll]

Thanks!

Lars

> On 18 Feb 2019, at 09:03, Kari Oikarinen <kari.oikarinen at 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.Rutledge at qt.io 
>>> <mailto:Shawn.Rutledge at qt.io>> wrote:
>>> 
>>> 
>>> 
>>>> On 16 Jan 2019, at 10:08, Lars Knoll <lars.knoll at qt.io 
>>>> <mailto:lars.knoll at qt.io>> wrote:
>>>> 
>>>>> On 16 Jan 2019, at 09:47, Alex Blasche <alexander.blasche at qt.io 
>>>>> <mailto:alexander.blasche at qt.io>> wrote:
>>>>> 
>>>>>> From: Development <development-bounces at qt-project.org 
>>>>>> <mailto:development-bounces at qt-project.org>> on behalf of Lars Knoll 
>>>>>> <lars.knoll at qt.io <mailto:lars.knoll at 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 at qt-project.org <mailto:Development at qt-project.org>
>>> https://lists.qt-project.org/listinfo/development
>> 
>> 
>> _______________________________________________
>> Gerrit-admin mailing list
>> Gerrit-admin at 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.oikarinen at qt.io
> +358 50 5281010
> http://qt.io
> ---