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.
Releases always happen on the X.Y branch. The release itself is a tagged commit.
2. Create a pulpcore (Not Shared) Sprint/Milestone with the name of the release, e.g. 3.0.1. You can do this here. Assign issues to be released to the milestone (running the release script (step 3) will give you a redmine query for all unassigned issues).
python .ci/scripts/release.py release_type lower_pulpcore_version upper_pulpcore_version command.
Dependencies: pip install gitpython bump2version towncrier python-redmine
python3 .ci/scripts/release.py major
python3 .ci/scripts/release.py minor --lower 3.8 --upper 4.0
More info on:
python3 .ci/scripts/release.py --helphttps://pulp.plan.io/projects/pulp/wiki/Release_script
4. Copy the commit printed by the script. You will tag it later. If you perform
git log you will see already committed changes.
5. Make a PR and merge it.
6. 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
7. Push the tag with
git push origin 3.0.1.
8. Create the github release from the tag. After the PR is merged, go to https://github.com/pulp/pulpcore/releases/new to create a new release from the existing tag.
9 Creating a new tag starts a CI job that pushes the package to PyPI. Monitor the job from Github Actions. After the job is done, validate that the new package is on PyPI.
10. The release script should do all the Redmine steps below, just check that it's complete.
- 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
11. 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.
12. Announce to firstname.lastname@example.org with a summary of all the changes.
13. 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
14. 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.:
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 https://github.com/pulp/pulpcore 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 setup.py, pulpcore/app/__init__.py, and .bumpversion.cfg to the next z-release. So if you are making 3.1.0, the 3.1 branch would become 3.1.1.dev.
4. Commit the version bump to the 3.y branch you created
5. At the
Y-release branch, update the following variables in template_config.yml and then use the plugin_template to update the CI config files (eg
./plugin-template --github pulpcore):
pulpcore_branch: set it to the current pulpcore release (eg "3.1.0").
pulpcore_pip_version_specifier: eg "~=3.1.0"
6. After you have branched and updated stable_branch, remove the "Needs Cherry Pick" label from all closed issues.
Releasing a Plugin¶
Releasing a plugin has the same process as described above except it happens on the plugin repo instead of https://github.com/pulp/pulpcore
Criteria to have the Y release for plugins¶
If any of the following is true, release a new Y release of your plugin, otherwise release a Z release.
- at least one new feature is introduced (it's usually a story or a task in Redmine and it often has .feature changelog file)
- a floor version bump (Y release) in any dependency
- including pulpcore (E.g. it was pulpcore>=3.3 and it becomes pulpcore>=3.9)
- a django migration which needs to go into a release
- Create a fork of the release branch you want to cherrypick the change to (e.g.
git checkout 3.12 && git checkout -b 3.12-cherrypicks)
- Use the cherrypick script to cherry pick the change (e.g. for backport 4567 that backports issue 1234 with commit abcd1234, run
.ci/scripts/cherrypick.sh abcd1234 1234 4567)
- Repeat step 2 as many times as necessary if there are multiple backports
- Push and open a PR against the release branch
Note: some older branches may not have the cherrypick script. It may be necessary to add this script to the release branch:
git checkout master -- .ci/scripts/cherrypick.sh git commit -m "Added cherrypick script [noissue]" # or git update-index --assume-unchanged .ci/scripts/cherrypick.sh