Project

Profile

Help

Release Guide » History » Sprint/Milestone 6

ipanova@redhat.com, 10/06/2021 02:57 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 3 lmjachky
## Preparing a Y-release
57
58
1. Update the CI config and workflows by running `./plugin-template --github PLUGIN_NAME`.
59
60 6 ipanova@redhat.com
2. Start the ``Create New Release Branch`` workflow from the master branch in GitHub.
61 3 lmjachky
62 6 ipanova@redhat.com
3. Checkout the new branch locally.
63 1 dkliban@redhat.com
64 6 ipanova@redhat.com
4. Pin the upper bound of pulpcore in ``requirements.txt``. Update ``template_config.yml`` with new values for ``pulpcore_branch`` and ``pulpcore_pip_version_specifier``.
65 1 dkliban@redhat.com
66 6 ipanova@redhat.com
5. Re-run plugin-template (e.g.: ./plugin-template --github pulp_file). Commit changes and make a PR against the new branch. Merge the PR.
67
68
6. Ensure yourself you have configured secrets required for publishing docs/packages as the Pulp user in a GitHub repository.
69
70
7. Start the ``Release Pipeline`` workflow and specify the tag name that is equal to the milestone specified in the corresponding Redmine project.
71
72
73
74 3 lmjachky
75
## Preparing a Z-release
76
77
Releasing a new Z-version of a particular plugin has the same workflow as described above.
78 1 dkliban@redhat.com
79
## Criteria to have the Y release for plugins
80
81
If any of the following is true, release a new Y release of your plugin, otherwise release a Z release.
82
 * at least one new feature is introduced (it's usually a story or a task in Redmine and it often has .feature changelog file)
83
 * a floor version bump (Y release) in any dependency
84
    *  including pulpcore (E.g. it was pulpcore>=3.3 and it becomes pulpcore>=3.9)
85
 * a django migration which needs to go into a release
86
87
88
# Cherrypicking backports
89
90
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`)
91
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`)
92
3. Repeat step 2 as many times as necessary if there are multiple backports
93
4. Push and open a PR against the release branch
94
95
Note: some older branches may not have the cherrypick script. It may be necessary to add this script to the release branch:
96
97
```
98
git checkout master -- .ci/scripts/cherrypick.sh
99
git commit -m "Added cherrypick script [noissue]"  # or git update-index --assume-unchanged .ci/scripts/cherrypick.sh
100
```