Skip to content

Commit 8c9fc9e

Browse files
pierreprinettiEmilienM
authored andcommitted
RELEASE.md: List PRs from last release
Stop relying on milestones. A release process based on milestones is prone to error (because not all PRs were necessarily added to the right milestone), and moreover it is not applicable to the cherry-pick workflow. Instead, this new release process uses `gh` to retrieve all PRs since a given release.
1 parent 51f2469 commit 8c9fc9e

File tree

1 file changed

+37
-16
lines changed

1 file changed

+37
-16
lines changed

RELEASE.md

+37-16
Original file line numberDiff line numberDiff line change
@@ -15,36 +15,57 @@ Automation prevents merges if the label is not present.
1515

1616
### Metadata
1717

18-
The release notes for a given release are generated based on the PR title and its milestone:
19-
* make sure that the PR title is descriptive
20-
* add a milestone based on the semver label: x++ if major, y++ if minor, z++ if patch.
18+
The release notes for a given release are generated based on the PR title: make
19+
sure that the PR title is descriptive.
2120

2221
## Release of a new version
2322

24-
### Step 1: Check the metadata
23+
Requirements:
24+
* [`gh`](https://github.com/cli/cli)
25+
* [`jq`](https://stedolan.github.io/jq/)
2526

26-
Check that all pull requests merged since the last release have the right milestone.
27+
### Step 1: Collect all PRs since the last release
2728

28-
### Step 2: Release notes and version string
29+
Supposing that the base release is `v1.2.0`:
30+
31+
```
32+
for commit_sha in $(git log --pretty=format:"%h" v1.2.0..HEAD); do
33+
gh pr list --search "$commit_sha" --state merged --json number,title,labels,url
34+
done | jq '.[]' | jq --slurp 'unique_by(.number)' > prs.json
35+
```
36+
37+
This JSON file will be useful later.
38+
39+
### Step 2: Determine the version
40+
41+
In order to determine the version of the next release, we first check that no incompatible change is detected in the code that has been merged since the last release. This step can be automated with the `gorelease` tool:
2942

30-
Once all PRs have a sensible title and are added to the right milestone, generate the release notes with the [`gh`](https://github.com/cli/cli) tool:
3143
```shell
32-
gh pr list \
33-
--state merged \
34-
--search 'milestone:vx.y.z' \
35-
--json number,title \
36-
--template \
37-
'{{range .}}* {{ printf "[GH-%v](https://github.com/gophercloud/gophercloud/pull/%v)" .number .number }} {{ .title }}
38-
{{end}}'
44+
gorelease | grep -B2 -A0 '^## incompatible changes'
3945
```
4046

41-
Replace `x.y.z` with the current milestone.
47+
If the tool detects incompatible changes outside a `testing` package, then the bump is major.
48+
49+
Next, we check all PRs merged since the last release using the file `prs.json` that we generated above.
50+
51+
* Find PRs labeled with `semver:major`: `jq 'map(select(contains({labels: [{name: "semver:major"}]}) ))' prs.json`
52+
* Find PRs labeled with `semver:minor`: `jq 'map(select(contains({labels: [{name: "semver:minor"}]}) ))' prs.json`
53+
54+
The highest semver descriptor determines the release bump.
55+
56+
### Step 3: Release notes and version string
57+
58+
Once all PRs have a sensible title, generate the release notes:
59+
60+
```shell
61+
jq -r '.[] | "* [GH-\(.number)](\(.url)) \(.title)"' prs.json
62+
```
4263

4364
Add that to the top of `CHANGELOG.md`. Also add any information that could be useful to consumers willing to upgrade.
4465

4566
**Set the new version string in the `DefaultUserAgent` constant in `provider_client.go`.**
4667

47-
Create a PR with these two changes. The new PR should be labeled with the semver label corresponding to the type of bump, and the milestone corresponding to its version.
68+
Create a PR with these two changes. The new PR should be labeled with the semver label corresponding to the type of bump.
4869

4970
### Step 3: Git tag and Github release
5071

0 commit comments

Comments
 (0)