[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