[Development] QtCS2019 Notes from "Branch Policy" discussion

[Edward Welbourne]

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.