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 master called “pulp-x.y”.
- In 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 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 master.
- Follow the release steps, which will bump version numbers and grow the change log.
- Merge pulp-x.y into 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
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 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 master branch’s history, but the actual code changes that took place will not be applied to the master branch.
If step 3 were not performed, every future branch of pulp-x.y would have a conflict with master over the version and changelog. Merging immediately after the release with the “ours” strategy effectively resolves that conflict.