Release Management

This page explains processes that should be carried out by a Release Manager only.

Branch Management

To create a new release branch, follow these steps.

  1. Create a new branch from master called “pulp-x.y”.
  2. 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.

  1. make sure pulp-x.y is fully merged into master.
  2. Follow the release steps, which will bump version numbers and grow the change log.
  3. 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.0 will 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

Note

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.