Project

Profile

Help

Release Guide » History » Sprint/Milestone 2

bmbouter, 09/02/2021 08:49 PM

1 1 dkliban@redhat.com
# Release Guide
2
3
The following guide provides step-by-step instructions for releasing pulpcore and most plugins.
4
5
Releases **always** happen on the X.Y branch.
6
7
## Preparing a Y-release
8
9
These steps are specific for releasing a y-release.
10
11
1. If [plugin_template/CHANGES](https://github.com/pulp/plugin_template/tree/master/CHANGES) dir is not empty: [build a new changelog and tag the plugin_template](https://github.com/pulp/plugin_template#tagging-plugin_template).
12
13
2. Update master branch with the latest GHA config from plugin_template
14
15
3. Run the "Create New Release Branch" from `master` branch. You need to specify the name of the new branch (e.g.: 1.7).
16
17
4. Checkout the new branch locally.
18
19
5. Update the upper bound of pulpcore in requirements.txt.
20
21
6. Update template_config.yml with new values for "pulpcore_branch" and "pulpcore_pip_version_specifier". 
22
23
7. Re-run plugin-template (e.g.: `./plugin-template --github pulp_file`).
24
25
8. Commit changes and make a PR against the new branch. Merge the PR.
26
27
## Releasing (Start here for Z stream)
28
29
1. Create a Sprint/Milestone (Not Shared) with the name of the release, e.g. 1.7.0. You can do this [here](https://pulp.plan.io/projects/pulp/settings/versions) for pulpcore. 
30
31
2. Go to the Release Pipeline workflow (for pulpcore, this is at https://github.com/pulp/pulpcore/actions/workflows/release.yml) and start a new release by clicking the `Run Workflow` button and entering the release branch and the release tag you want to release (e.g.: 1.7.0).
32
33
3. Monitor the job. Ensure it creates the tag, the pypi release, the client releases on pypi and rubygems, and updates the docs on docs.pulpproject.org.
34
35
4. Merge the changelog PR produced by the Release Pipeline workflow into `master` branch.
36
37
5. The release script should do all the Redmine steps below, just check that it's complete.
38
39
  - Ensure all tickets are at MODIFIED and in the "pulpcore" project. Clean them up if not.
40
  - Set all tickets named in the changelog to CLOSED - CURRENT RELEASE
41
  - Set the Sprint/Milestone to the one created \^
42
  - "close" the milestone, that is done [here](https://pulp.plan.io/projects/pulp/settings/versions)
43
44
6. 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.
45
46 2 bmbouter
7. Announce to https://discourse.pulpproject.org/ and pulp-list@redhat.com with a summary of all the changes.
47 1 dkliban@redhat.com
48
8. If you did a pulpcore y-release, update the supported-releases.json file [here](https://raw.githubusercontent.com/pulp/pulp-ci/master/ci/config/releases/supported-releases.json) to the 3.y version in a PR like [this one](https://github.com/pulp/pulp-ci/pull/696). This drives a javascript banner on docs.pulpproject.org and if not set correctly the latest, supported Y-release will show a banner (incorrectly) that this version is unsupported.
49
50
9. If releasing pulpcore, you must also release pulp_installer. The release guide is [here](https://github.com/pulp/pulp_installer/blob/master/RELEASING.md).
51
52 2 bmbouter
10. Start a "Publish OCI Images" workflow with the branch matching the corresponding pulpcore minor release to get the changes in the single container. You can do this at https://github.com/pulp/pulp-oci-images/actions/workflows/publish_images.yaml
53 1 dkliban@redhat.com
54
# Releasing a Plugin
55
56
Releasing a plugin has the same process as described above except it happens on the plugin repo instead of https://github.com/pulp/pulpcore
57
58
## Criteria to have the Y release for plugins
59
60
If any of the following is true, release a new Y release of your plugin, otherwise release a Z release.
61
 * at least one new feature is introduced (it's usually a story or a task in Redmine and it often has .feature changelog file)
62
 * a floor version bump (Y release) in any dependency
63
    *  including pulpcore (E.g. it was pulpcore>=3.3 and it becomes pulpcore>=3.9)
64
 * a django migration which needs to go into a release
65
66
67
# Cherrypicking backports
68
69
1. 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`)
70
2. 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`)
71
3. Repeat step 2 as many times as necessary if there are multiple backports
72
4. Push and open a PR against the release branch
73
74
Note: some older branches may not have the cherrypick script. It may be necessary to add this script to the release branch:
75
76
```
77
git checkout master -- .ci/scripts/cherrypick.sh
78
git commit -m "Added cherrypick script [noissue]"  # or git update-index --assume-unchanged .ci/scripts/cherrypick.sh
79
```