Improve release instructions #647
Conversation
|
What do you think should be considered as a patch release over a standard minor release? |
| users will see goes first, changes that affect developers/API users should go | ||
| last). Minor changes that are related to repo maintenance can be ignored. | ||
|
|
||
| Do not forget to list **ALL** the PRs that have been merged since the last |
There was a problem hiding this comment.
How do you think we should document the stray commits that occasionally get pushed without an associated PR?
There was a problem hiding this comment.
There's somewhat of a convention in how each PR is listed so maybe we could document that?
Here's how I understand it at least:
| Do not forget to list **ALL** the PRs that have been merged since the last | |
| Do not forget to list **ALL** the PRs that have been merged since the last | |
| release, with the proper links. | |
| The pull requests should be listed from the most recently merged to the oldest. Each entry should roughly follow this template: | |
| `{Summary} (#{PR Number}, by/thanks @{Author})` | |
| If the pull request is by a core team member they should be attributed with `by @{Author}` | |
| Otherwise the PR author should be attributed with `thanks @{Author}` |
There was a problem hiding this comment.
How do you think we should document the stray commits that occasionally get pushed without an associated PR?
Hmm, that's a good question. For "revert" commits, I think we can simply remove the associated PR from the list, or at least mark it as (reverted). For the rest I don't know. That's the reason why I'd like to enfore the "always make PRs" policy, and keep stray commits to fix bugs/typos in a recently merged PR.
There's somewhat of a convention in how each PR is listed so maybe we could document that?
Yeah, That's a good idea!
Here's how I understand it
That's it, except that I used the PR title, rather than a summary. I often had to reword PRs on github to make the title more meaningful than fix bug #123...
This is explained in the preamble. IIRC that's what we agreed upon back then, but we can always improve it if needed. |
Co-authored-by: syeopite <[email protected]>
As requested by unixfox, this improves the release process instructions. I also fixed some typos here and there.