[Development] Qt branches & proposal how to continue with those

Jani Heikkinen jani.heikkinen at qt.io
Mon Feb 5 13:39:47 CET 2018


Hi,

So the decision how to proceed is done. Let's give everyone a while to finalize ongoing tasks and put the decision in effect after a week. 

So from 12.2.2018 ->
   - '5.9' will be in cherry-pick mode
   - '5.10' will be closed

We will make sure final merges from '5.9' -> '5.10' -> '5.11' will be done after that and then there will be merges only from '5.11' -> 'dev'

br,
Jani
________________________________________
From: Development <development-bounces+jani.heikkinen=qt.io at qt-project.org> on behalf of Lars Knoll <lars.knoll at qt.io>
Sent: Monday, February 5, 2018 12:35 PM
To: Qt development mailing list
Subject: Re: [Development] Qt branches & proposal how to continue with those

Hi all,

Sorry for being a bit late with answering to this thread. Been first traveling and then was down with a flu last week.

Unfortunately, none of the options on the table will be 100% satisfying to everybody. This is basically because we have limits on how much work we can or should be doing getting different releases out, and different users have different preferences with regards to our branches.

I think that we’ll be long term best off, if we move Qt forward as quickly as we can. Qt 5.11 provides some significant new things over 5.10, so in the end we should prioritise finalising that branch and getting 5.11.0 out as quickly as we can. Less merging will free up people and CI capacity to focus on 5.11 bug fixing and speed up turn around time to getting qt5.git integrations through.

This means we’ll go with something close to option 2b that Ossi outlined below:

* We put 5.9 in cherry-picking mode in line with QUIP 5.
* There is currently no 5.10.2 release planned. The main reason to do one would be to be an urgent security update. This means we also leave 5.10 branch behind and close it.
* If we have a larger security issue that deserves a release (and not just a patch) from 5.10, we can still do that from the branch on top of 5.10.1 (maybe doing a one time merge from 5.9 to 5.10 if we want those fixes as well)
* Instead we put our focus on getting 5.11 out as quickly as we can. Let’s branch now, create first alpha and then beta packages as quickly as possible. Not having to merge from 5.10 will ease this significantly. Getting 5.11 out quick will hopefully also make Webengine not fall too far/long behind upstream security patches.

Of course, we continue having regular releases from 5.9, but with it being in strict mode, the frequency of releases will maybe drop a bit (from every 6 weeks currently to maybe every 8-10 weeks). Let’s also now plan for at least two patch level releases of 5.11 before 5.12 comes out.

Cheers,
Lars

> On 1 Feb 2018, at 15:53, Oswald Buddenhagen <Oswald.Buddenhagen at qt.io> wrote:
>
> On Thu, Feb 01, 2018 at 02:35:58PM +0100, Tuukka Turunen wrote:
>> So based on this Qt 5.9 should be in cherry pick mode next week. With
>> previous wording it should have been in cherry pick mode from 2.9.2017
>> onwards, which was way too soon (hence the change to QUIP5).
>>
> right.
>
>> What about Qt 5.10.2? This of course needs to be addressed after we
>> see how Qt 5.10.1 turns out to be. But provided Qt 5.10.1 is a good
>> release, I would like to put full focus into getting Qt 5.11.0 out
>> quickly and try to release Qt 5.11.1 in June already.
>>
> yes, but the point is that we can't change the policy retroactively. if
> 5.10.2 is an option, then 5.10 needs to stay open as the default target
> for fixes, and be forward-merged. this leaves us at two merges for a fix
> to reach dev.
> the same delay would occurr if we closed 5.10 and continued to merge
> from 5.9, which is why the discussion which one is more important
> emerged.
>
> this leaves us with three options:
> 1)
> - 5.9 goes to cherry-pick mode, essentially now.
> - 5.10 stays open until 5.11.0 is released.
>   - we should create 5.10.2 before the 5.11.0 release even if we don't
>     intent to actually make a release, just so we have a mergable
>     target branch (to avoid "illegal" 5.10 => 5.11.0 merges or
>     cherry-picks).
> 2)
> - we just declare that there won't be 5.10.2 and close 5.10 after
>   5.10.1. potentially not user-friendly, but we've done it in the
>   past, and while releasing capacity isn't the limiting factor now,
>   forward-merging apparently is.
> 2a) we continue to forward-merge from 5.9.
> 2b) 5.9 goes to cherry-pick mode, which cuts out another merge step.
>
> note that 5.10 going to cherry-pick mode is specifically not an option,
> as stated previously.
>
> 1) seems most natural to me.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list