Pulp3 Release Guide¶
This serves as a step-by-step guide to implement a Pulp 3 release.
Preparing a Y-release¶
If you are creating a z-stream release, e.g. 3.0.1, work on the existing X.Y branch, e.g. 3.0 and continue to the next section. If you are creating a Y-release follow these instructions first:
1. Create the new X.Y branch from a clean checkout of the latest remote 'master'. For example to make the 3.0 branch we ran:
# assumes the remote 'pulp' is https://github.com/pulp/pulpcore git fetch pulp git checkout pulp/master git reset --hard HEAD git checkout -b 3.0 git push pulp 3.0
2. Increment the versions in setup.py, docs/conf.py, and pulpcore/__init__.py to the next y-release. So if you are making 3.0.0, master would become 3.1.0.dev.
3. Commit the version bump
4. Make a PR and merge against 'master'. This fully prepares the master branch for the next Y-version development.
Releases always happen on the X.Y branch. The release itself is a tagged commit.
1. Increment the versions in setup.py, docs/conf.py, and pulpcore/__init__.py to the release versions. e.g. 3.0.1
2. Commit the version bump (first commit)
3. Build the changelog with the
towncrier command, this will stage git changes for you.
4. Commit the changelog by itself. (second commit)
5. Increment the versions in setup.py, docs/conf.py, and pulpcore/__init__.py to the next, unreleased version. e.g. 3.0.2.dev
6. Commit the version bump (third commit)
7. Make a PR and merge it.
8. Make a tag of the "second commit" from above. That one has the changelog and a correct version number. Tag it with e.g.
git tag 3.0.1 9fceb02
9. Push the tag with
git push origin 3.0.1.
10. 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.
11. Creating a new tag starts a Travis job that pushes the package to PyPI. Go to https://travis-ci.com/pulp/pulpcore/builds and monitor the job. After the job is done, validate that the new package is on PyPI.
12. 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: https://pulp.plan.io/issues?set_filter=1&status_id=*&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 creatd ^
- "close" the milestone, that is done here
13. Announce to firstname.lastname@example.org with a summary of all the changes.
14. 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
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 https://github.com/pulp/pulpcore