-
Notifications
You must be signed in to change notification settings - Fork 844
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
Add Release.md #5622
base: trunk
Are you sure you want to change the base?
Add Release.md #5622
Conversation
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.
Noticed a few typos while reading. Hope this is helpful!
Co-authored-by: Imbris <[email protected]>
@Imberflur thanks! |
I'll take on review for this. Warning: I'll have a lot of (non-blocking) feedback (😅), but I think this is a big net improvement over nothing. |
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.
I think this is an overall massive improvement over having nothing written.
I've hit my timebox for feedback for this round, and I suspect I'll have more once I dedicate more time to this. However, I'm happy to implement even this feedback I have as an additional PR. I think all the important details are already in this new document, and waiting to land it for perfection sounds counterproductive.
I've noted things that I feel strongly about with checkboxes.
I used Conventional Comments in this review! I hope they help with clarity and tone. 🙂
|
||
## Major Release Process | ||
|
||
Approx 1 Week Before: |
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.
question: These seem like poor man's section headers. Why not formally make a section instead, i.e.:
Approx 1 Week Before: | |
### Approx. 1 Week Before | |
…?
This feedback also applies to other headers like it.
## Major Release Process | ||
|
||
Approx 1 Week Before: | ||
- Determine if `glow` (@groves), `metal-rs` (@kvark and @cwfitzgerald) or any other dependant crates will need a release. If so, coordinate with their maintainers. |
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.
question: Is there more specific direction we can give here? The only criteria I can think of is "make sure we're depending on published crates on Crates.io, rather than, say, git
dependencies".
## Major Release Process | ||
|
||
Approx 1 Week Before: | ||
- Determine if `glow` (@groves), `metal-rs` (@kvark and @cwfitzgerald) or any other dependant crates will need a release. If so, coordinate with their maintainers. |
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.
nitpick/typo: s/dependant/dependent in US English, though this is valid for British English.
suggestion: Note that we're talking about out-of-tree dependencies.
Combined feedback:
- Determine if `glow` (@groves), `metal-rs` (@kvark and @cwfitzgerald) or any other dependant crates will need a release. If so, coordinate with their maintainers. | |
- Determine if `glow` (@groves), `metal-rs` (@kvark and @cwfitzgerald) or any other dependent crates outside of the repo will need a release. If so, coordinate with their maintainers. |
|
||
## Patch Release Process | ||
- Enumerate all PRs that haven't been backported yet. These use the `needs-backport` label. [GH Link](https://github.com/gfx-rs/wgpu/issues?q=label%3A%22PR%3A+needs+back-porting) | ||
- On _your own branch_ based on the latest release branch. Cherry-pick the PRs that need to be backported. When modifying the commits, use --append to retain their original authorship. |
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.
typo: A comma should separate these otherwise incomplete sentences, not a period.
style: Backticks around CLI args., please!
issue: It's unclear what CLI you're actually talking about. --append
doesn't exist in the git-cherry-pick
or git-commit
CLIs. I suspect you meant the git commit --amend
flag? 🤔
Combined feedback:
- On _your own branch_ based on the latest release branch. Cherry-pick the PRs that need to be backported. When modifying the commits, use --append to retain their original authorship. | |
- On _your own branch_ based on the latest release branch, cherry-pick the PRs that need to be backported. When modifying the commits, use `--amend` to retain their original authorship. |
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.
Yes, I use a git gui so I click the button that starts with an a
:)
- On _your own branch_ based on the latest release branch. Cherry-pick the PRs that need to be backported. When modifying the commits, use --append to retain their original authorship. | ||
- Remove the `needs-backport` label from the PRs. | ||
- Fix the changelogs items and add a new header for the patch release with the release version and date. | ||
- Once all the PRs are cherry-picked, look at the diff between HEAD and the previous patch release. See what crates changed. |
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.
style: Backticks for refs., please!
suggestion: An example CLI invocation might be nice here.
- Once all the PRs are cherry-picked, look at the diff between HEAD and the previous patch release. See what crates changed. | |
- Once all the PRs are cherry-picked, look at the diff between `HEAD` and the previous patch release (i.e., via `git diff v0.20.0..HEAD`). See what crates changed. |
@@ -0,0 +1,79 @@ | |||
This is an overview of how to run wgpu releases. |
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.
style: backticks plz
suggestion: I'd like to distinguish wgpu
-the-crate from wgpu
-the-Git-repository.
This is an overview of how to run wgpu releases. | |
This is an overview of how to run releases in the `wgpu` repository. |
- Create a new release on the `wgpu` repo with the changelog and a tag called `vX.Y.Z`. | ||
- Create a branch with the with the new version `vX.Y` and push it to the repo. | ||
- Publish the link to the github release in the following places. | ||
- [r/rust](https://www.reddit.com/r/rust/). |
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.
thought: I see no direction regarding the title, but maybe we don't need it?
Provides an overview of our release process, so releases aren't single-bus factor anymore.