[Development] QtCS2019 Notes from "Branch Policy" discussion
Edward Welbourne
edward.welbourne at qt.io
Wed Nov 27 11:57:45 CET 2019
Volker Hilsheimer (26 November 2019 15:42) wrote:
[snip]
> If I understood and remember the discussion, then the proposed flow
> would be:
>
> * we make changes to e.g changes-5.12.7 in the 5.12 branch
> * once 5.12.7 is released, release team copies the file into dev, and
> makes a separate commit
> * that commit gets cherry-picked from dev down into 5.15 and 5.14
> using the standard process
>
> The rationale is that we have only a single such "forward-porting"
> commit for each release, and to the largest extend follow the standard
> process. The disadvantage is that the changes-5.12.7 file in dev will
> have a different history than the same file in 5.12.
>
> If I understand your proposal, the process would be:
> * changes files are updated directly in the release branch, e.g. 5.12
> (assuming that 5.12.7 is only for the release team anyway)
> * we cherry-pick each commit from there forward through 5.14, 5.15, dev
>
> The advantage here is that we can track each commit, and have the same
> history for those files. The disadvantage is that it’s a bigger
> departure from standard process, with more room for error and
> overhead.
Alternative proposal (possibly just a restatement):
* Fresh commits are normally only allowed on dev, with an exception for
changes files and last-minute hot-fixes on release branches.
* Every commit has a Pick-to: footer (or whatever name we chose)
that lists where it's to be cherry-picked to.
* When a commit merges and isn't itself a cherry-pick, it gets
cherry-picked to every branch named on its footer.
Then we don't handle forward-picks any differently than backward-picks,
aside from only allowing the former in rare cases; and we don't handle
hot-fixes any differently than change files. Simple rules are easy to follow.
Eddy.
More information about the Development
mailing list