mirror of
https://github.com/italicsjenga/winit-sonoma-fix.git
synced 2024-12-23 05:41:31 +11:00
Update changelog guidelines to prevent conflicts from blocking PRs (#2145)
* Update changelog guidelines to prevent conflicts from blocking PRs As per consensus in https://github.com/rust-windowing/winit/issues/2135 * Add note about whitespace in changelog * Add note about maintainer creating new tag
This commit is contained in:
parent
7cd273ae58
commit
2cc87cab65
2
.gitattributes
vendored
2
.gitattributes
vendored
|
@ -20,5 +20,3 @@
|
||||||
*.PDF diff=astextplain
|
*.PDF diff=astextplain
|
||||||
*.rtf diff=astextplain
|
*.rtf diff=astextplain
|
||||||
*.RTF diff=astextplain
|
*.RTF diff=astextplain
|
||||||
|
|
||||||
/CHANGELOG.md merge=union
|
|
||||||
|
|
|
@ -1,3 +1,11 @@
|
||||||
|
# Changelog
|
||||||
|
|
||||||
|
All notable changes to this project will be documented in this file.
|
||||||
|
|
||||||
|
Please keep one empty line before and after all headers. (This is required for `git` to produce a conflict when a release is made while a PR is open and the PR's changelog entry would go into the wrong section).
|
||||||
|
|
||||||
|
And please only add new entries to the top of this list, right below the `# Unreleased` header.
|
||||||
|
|
||||||
# Unreleased
|
# Unreleased
|
||||||
|
|
||||||
- **Breaking:** Rename the `Exit` variant of `ControlFlow` to `ExitWithCode`, which holds a value to control the exit code after running. Add an `Exit` constant which aliases to `ExitWithCode(0)` instead to avoid major breakage. This shouldn't affect most existing programs.
|
- **Breaking:** Rename the `Exit` variant of `ControlFlow` to `ExitWithCode`, which holds a value to control the exit code after running. Add an `Exit` constant which aliases to `ExitWithCode(0)` instead to avoid major breakage. This shouldn't affect most existing programs.
|
||||||
|
|
|
@ -25,7 +25,10 @@ When making a code contribution to winit, before opening your pull request, plea
|
||||||
- you updated any relevant documentation in winit
|
- you updated any relevant documentation in winit
|
||||||
- you left comments in your code explaining any part that is not straightforward, so that the
|
- you left comments in your code explaining any part that is not straightforward, so that the
|
||||||
maintainers and future contributors don't have to try to guess what your code is supposed to do
|
maintainers and future contributors don't have to try to guess what your code is supposed to do
|
||||||
- your PR adds an entry to the changelog file if the introduced change is relevant to winit users
|
- your PR adds an entry to the changelog file if the introduced change is relevant to winit users.
|
||||||
|
|
||||||
|
You needn't worry about the added entry causing conflicts, the maintainer that merges the PR will
|
||||||
|
handle those for you when merging (see below).
|
||||||
- if your PR affects the platform compatibility of one or more features or adds another feature, the
|
- if your PR affects the platform compatibility of one or more features or adds another feature, the
|
||||||
relevant sections in [`FEATURES.md`](https://github.com/rust-windowing/winit/blob/master/FEATURES.md#features)
|
relevant sections in [`FEATURES.md`](https://github.com/rust-windowing/winit/blob/master/FEATURES.md#features)
|
||||||
should be updated.
|
should be updated.
|
||||||
|
@ -34,9 +37,26 @@ Once your PR is open, you can ask for review by a maintainer of your platform. W
|
||||||
is that a PR must be approved by at least two maintainers of winit before being merged, including
|
is that a PR must be approved by at least two maintainers of winit before being merged, including
|
||||||
at least a maintainer of the platform (a maintainer making a PR themselves counts as approving it).
|
at least a maintainer of the platform (a maintainer making a PR themselves counts as approving it).
|
||||||
|
|
||||||
|
Once your PR is deemed ready, the merging maintainer will take care of resolving conflicts in
|
||||||
|
`CHANGELOG.md` (but you must resolve other conflicts yourself). Doing this requires that you check the
|
||||||
|
"give contributors write access to the branch" checkbox when creating the PR.
|
||||||
|
|
||||||
## Maintainers & Testers
|
## Maintainers & Testers
|
||||||
|
|
||||||
The current [list of testers and contributors](https://github.com/rust-windowing/winit/wiki/Testers-and-Contributors)
|
The current [list of testers and contributors](https://github.com/rust-windowing/winit/wiki/Testers-and-Contributors)
|
||||||
can be found on the Wiki.
|
can be found on the Wiki.
|
||||||
|
|
||||||
If you are interested in contributing or testing on a platform, please add yourself to that table!
|
If you are interested in contributing or testing on a platform, please add yourself to that table!
|
||||||
|
|
||||||
|
## Making a new release
|
||||||
|
|
||||||
|
If you believe a new release is warranted, you can make a pull-request with:
|
||||||
|
- An updated version number (remember to change the version everywhere it is used).
|
||||||
|
- A new section in the changelog (below the `# Unreleased` section).
|
||||||
|
|
||||||
|
This gives contributors an opportunity to squeeze in an extra PR or two that they feel is valuable
|
||||||
|
enough to warrant blocking the release a little.
|
||||||
|
|
||||||
|
Once the PR is merged, a maintainer will create a new tag matching the version name (e.g. `v0.26.1`),
|
||||||
|
and a CI job will automatically release the new version. Remember that the release date in the
|
||||||
|
changelog must be kept in check with the actual release date.
|
||||||
|
|
Loading…
Reference in a new issue