[Development] Qt 5.12 schedule proposal & proposal for release process change

Kari Oikarinen kari.oikarinen at qt.io
Tue Apr 17 12:18:40 CEST 2018



On 17.04.2018 12:08, Edward Welbourne wrote:
> Alex Blasche (maanantai 16. huhtikuuta 2018 16.47)
>>> ... I do like to emphasize though that the dates for first beta and
>>> first RC are important (and FF is alpha) because they define times
>>> when certain level of changes are no longer permitted (e.g. after
>>> first beta no API changes). Therefore, you will not get around setting
>>> a target date for first Beta and RC.
> 
> Jani Heikkinen (17 April 2018 08:28)
<snip>
>> So  I think the way to proceed with this should be like Lars proposed:
>> - Snapshot packages from the dev branch
>> - FF and branching occur together and packages are getting the ‘alpha’ tag
>> - Agree that we should start with the API review immediately.
>> - Beta once API review is done. Lets agree the 'Done' properly to get
>>    it clear for everyone. I already tried to start discussion about it in
>>    http://lists.qt-project.org/pipermail/development/2018-March/032338.html
<snip>
>> - RC once we have the release branch and all currently known blockers are fixed
> 
> You'll have the release branch just after alpha, if you follow the plan
> above, so the only condition left here is the known blockers.  Even on
> those, we've had some flexibility in the past - some blockers do get
> downgraded sometimes - which can serve to steer a release towards
> fitting a schedule.

For example with 5.11.0 release there's two branching points for
branches 5.11 and 5.11.0. Maybe with release branch the latter is meant?

So dev -> 5.12 branching would happen at feature freeze and 5.12 ->
5.12.0 branching would happen in the transition to RC?

A good naming convention for those branches might help keep them
separate. "Minor branches" and "release branches" maybe?

-- 
Kari



More information about the Development mailing list