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

[Kari Oikarinen]

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
---