-
Notifications
You must be signed in to change notification settings - Fork 163
Improve release instructions #647
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
What do you think should be considered as a patch release over a standard minor release? |
@@ -34,13 +34,14 @@ 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 <70992037+syeopite@users.noreply.github.com>
As requested by unixfox, this improves the release process instructions. I also fixed some typos here and there.