Conversation
|
Excellent writing and super helpful as usual. Thanks Pierre! |
07f1f69 to
8e59aff
Compare
| The Go mod system relies on Git tags. In order to simulate a review mechanism, we rely on Github to create the tag through the Release mechanism. | ||
|
|
||
| * [Prepare a new release](https://github.com/gophercloud/gophercloud/releases/new) | ||
| * Let Github generate the release notes by clicking on Generate release notes |
There was a problem hiding this comment.
I find the What's Changed section of the github generated release notes to be a lot less informative than the content of the CHANGELOG file, as it can contain a lot of PRs users do not care about (for instance, maintenance of the CI jobs). Can we suggest copying the content of the CHANGELOG rather than a boring list of all PRs?
That said, I love the New Contributors section and would like it to stay.
There was a problem hiding this comment.
Maybe we can figure out a gh command to pull out new contributors, so that we have them in the CHANGELOG and just copy paste the whole thing in the release
|
|
||
| **Set the new version string in the `DefaultUserAgent` constant in `provider_client.go`.** | ||
|
|
||
| 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. |
There was a problem hiding this comment.
I'm probably missing something obvious. I can see why the release prep PR could have a label of semver:patch or semver:minor if we're considering the the user agent bump is an API change, but it's not clear to me why it should have the same semver label as the type of release we're doing. Can you explain the logic?
There was a problem hiding this comment.
Totally arbitrary. That PR is not supposed to to anything to the code (except for the string bump now!), so I was unsure what label to apply (since our automation demands a label). I thought to apply the label that corresponds to the type of bump, just to add some info.
We can do whatever, and I’m open to suggestions.
|
|
||
| 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: | ||
| ```shell | ||
| gh pr list \ |
There was a problem hiding this comment.
For later, we could think of a script to help prepare for the release:
- fetch all PRs that have merged since last release
- propose a new version based on the semver label of these PRs
- check that all relevant PRs (the ones that need a line in the changelog) have the appropriate milestone and set it if not
- generate changelog
There was a problem hiding this comment.
absolutely. Also, once a script is in place we might not even strictly need milestones any more.
There was a problem hiding this comment.
absolutely. Also, once a script is in place we might not even strictly need milestones any more.
|
I propose to merge this as a first attempt. We can always make it better later. Unless anyone has a precise idea how to fix the issues reported in comments. |
No description provided.