This page explains processes that should be carried out by a Release Manager only.
To create a new release branch, follow these steps.
Create a new branch from 2-master called “pulp-x.y”.
In 2-master, bump all versions to x.(y+1).
Work can now continue as normal. Bug and feature branches can branch from the “pulp-x.y” branch and be merged into both “pulp-x.y” and 2-master.
When it is time to release version x.y.(z+1), follow these steps. There should be a branch freeze during this operation.
make sure pulp-x.y is fully merged into 2-master.
Follow the release steps, which will bump version numbers and grow the change log.
Merge pulp-x.y into 2-master (and every release branch greater than x.y) using the “ours” strategy. This ignores the file changes from step 2, but makes sure that pulp-x.y is still fully merged into 2-master. To protect from a race condition where someone might commit or merge to pulp-x.y between steps 1 and 3, merge a specific commit instead of a branch name. For example,
git show pulp-2.0will show a commit ID on the first line, and then you can merge that commit as shown below.
$ git checkout 2-master $ git merge -s ours b41f5b49
The “ours” strategy merges from the specified branch, but it ignores all changes from that branch. Thus, each change set from pulp-x.y will become a part of the 2-master branch’s history, but the actual code changes that took place will not be applied to the 2-master branch.
If step 3 were not performed, every future branch of pulp-x.y would have a conflict with 2-master over the version and changelog. Merging immediately after the release with the “ours” strategy effectively resolves that conflict.