Qt Contributors Summit 2019 - Branch Policy

Discussed and Agreed Proposal

We move to a workflow where we make all changes in dev, and then cherry-pick relevant changes from dev down into more stable branches
We are automating the cherry-picking with a bot that interprets a commit footer. That makes the cherry-picking part of the review and approval (approver has to confirm that patch is applicable for a stable branch)
cherry-picks inherit the review/approval of the original change
if no conflicts, they are staged automatically (but only once); if conflict, result is a new code review that original author needs to amend

We start with Qt 5.15/14/12 (ie 5.15 is “dev” in the Qt 5 series), and continue to merge 5.15 into dev until 5.15 has reached feature freeze.

Changes file updates are done in the relevant release branch; the files are then carried forward to dev, and cherry-picked down from there as usual
In exceptional cases, and to unblock a release, changes might go first into a release branch and cherry-picked forward into dev
- another exception is fixes in stable branches that are not relevant for dev

people are not used to having to work on dev; even with now defaulting clones to dev
it might generate more work for maintainers
another commit footer that introduces clutter
without merging, it might become more difficult to find out where a patch landed
merge conflicts need to be resolved potentially repeatedly (for each cherry-pick), vs a merge where resolutions are recorded; we assume this to be a rare situation
load on CI might increase (more frequent, smaller changes, rather than occasional merge change)