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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
