Pulp3 Release Guide

This serves as a step-by-step guide to implement a Pulp 3 release.

Don't forget to sync up with the installer team, a new installer release is needed for each new Y-release.

Releasing Pulpcore

Releases always happen on the X.Y branch. The release itself is a tagged commit.

1. Run python .travis/ release_type lower_pulpcore_version upper_pulpcore_version command.

Dependencies: pip install gitpython bump2version


for pulpcore: python3 .travis/ major

for plugins: python3 .travis/ minor --lower 3.8 --upper 4.0

More info on: python3 .travis/ --help

2. Copy the commit printed by the script. You will tag it later. If you perform git log you will see already committed changes.

3. Make a PR and merge it.

4. Make a tag of the "commit" from step 2. That one has the changelog and a correct version number. Tag it with e.g. git tag 3.0.1 9fceb02

5. Push the tag with git push origin 3.0.1.

6. Create the github release from the tag. After the PR is merged, go to to create a new release from the existing tag.

7. Creating a new tag starts a Travis job that pushes the package to PyPI. Go to and monitor the job. After the job is done, validate that the new package is on PyPI.

8. Create a pulpcore (Not Shared) Sprint/Milestone with the name of the release, e.g. 3.0.1. You can do this here Then do these Redmine steps below. To make this easier, I take the issue IDs and for a query like this:*&issue_id=5707,5894,5896,5941,5955,5955,5833,5867,5870,5873,5706,5941

  • Ensure all tickets are at MODIFIED and in the "pulpcore" project. Clean them up if not.
  • Set all tickets named in the changelog to CLOSED - CURRENT RELEASE
  • Set the Sprint/Milestone to the one created ^
  • "close" the milestone, that is done here

9. If doing a Y-release check for any issues still at MODIFIED. Ping any assignees/teams to close out these issues. Ideally, there should be no issues still at MODIFIED.

10. Announce to with a summary of all the changes.

11. If making a z-stream release, cherry pick the change log (second commit) to the 'master' branch such as git cherry-pick -x 420dd1ff2f326db454b216f33d848d5267489dfb and merge it to master via a PR

12. If making a y-stream release, create branch and push branch from the tag. See docs on this step in the section below.

Preparing a Y-release

If you are creating a y-stream release, e.g. 3.1.0, you'll need to perform branching. If making a z-stream release you don't need to do this section because you already have a branch to work on.:

1. Update the supported-releases.json file here to the 3.y version in a PR like this one. This drives a javascript banner on and if not set correctly the latest, supported Y-release will show a banner (incorrectly) that this version is unsupported.

2. Create the new X.Y branch from a clean checkout of the y-release tag. For example to make the 3.1 branch from 3.1.0 we ran:

git fetch pulp    # assumes the remote 'pulp' is
git checkout 3.1.0    # This is the tag you're branching from
git reset --hard 3.1.0
git checkout -b 3.1
git push pulp 3.1

3. Increment the versions in and pulpcore/ to the next z-release. So if you are making 3.1.0, the 3.1 branch would become

4. Commit the version bump to the 3.y branch you created

5. Update the stable_branch variable in template_config.yml and set it to the branch you just created (eg "3.1"). This is used to determine the latest stable branch when for example the cherry pick processor needs to cherry pick commits.

6. After you have branched and updated stable_branch, remove the "Needs Cherry Pick" label from all closed issues.

Cherry Picking Process

For pulpcore, Travis has a cron job that runs and checks merged PRs for the 'Needs Cherry Pick' label. Any PR that has that label will be cherry picked and included on a PR which is then tested per the usual process. A human merged that final PR and the label is removed.

Other plugins can opt in to using the plugin_template "cherry_pick_automation" variable. See the plugin_template docs for more infomartion on opting in to this CI/CD feature.

Releasing a Plugin

Releasing a plugin has the same process as described above except it happens on the plugin repo instead of

For pulp_rpm, see Pulp 3 RPM Release Guide.