Git procedures revisited Our procedures so far Branches

Git procedures revisited

Our procedures so far • Branches, release tags • master • Holds all commits except backward incompatible changes to current release series • A tag on master signifies a release (or release candidate) • next • Branch to be merged into master before next major release series • Holds all commits including any backward incompatible commits to current major release series • Semi-short-lived development branches for collaborative development

Possible changes 1. tag-6. 1. 0 • Only create at the moment there actually are backward incompatible changes • Only actually makes sense at that point • Have been “dragging” along next branch since we went to Git in order to gain experience and practice procedures handling the next branch tag-6. 1. 0 rc 2. Next branch Release branches? • Instead of tagging on master, create a release branch that will hold release candidates and final release tag • Will require cherrypicking from master in the period between the release branch is created and the final release is tagged. • Cherrypicking can be made “automatic” in a similar way as we have today – using a label to activate the arcbot. • Will be a ”cactus” model – release branches are never merged back into master. branch 6. 1. 0 cherrypick master next

Merge and commit policy • Have allowed direct commits to master to change minor things like README-files, arc. conf. reference etc • Creates a bit of a mess since the changes are then not automatically copied to next branch • Subsequent merge requests of development branch to the next branch will include the “forgotten” commits • Also not so clean for automatic creation of release notes – as labelling is not included etc • Suggestion: Always require merge requests