From 2cc87cab655060ade88ad8033e88cf86c6e45ac4 Mon Sep 17 00:00:00 2001 From: Mads Marquart Date: Sun, 23 Jan 2022 13:55:33 +0100 Subject: [PATCH] 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 --- .gitattributes | 2 -- CHANGELOG.md | 8 ++++++++ CONTRIBUTING.md | 22 +++++++++++++++++++++- 3 files changed, 29 insertions(+), 3 deletions(-) diff --git a/.gitattributes b/.gitattributes index 81f4fe3a..412eeda7 100644 --- a/.gitattributes +++ b/.gitattributes @@ -20,5 +20,3 @@ *.PDF diff=astextplain *.rtf diff=astextplain *.RTF diff=astextplain - -/CHANGELOG.md merge=union diff --git a/CHANGELOG.md b/CHANGELOG.md index d7ccaba2..72fd7d72 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -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 - **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. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0657334f..5f90b74d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -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 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 -- 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 relevant sections in [`FEATURES.md`](https://github.com/rust-windowing/winit/blob/master/FEATURES.md#features) 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 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 The current [list of testers and contributors](https://github.com/rust-windowing/winit/wiki/Testers-and-Contributors) can be found on the Wiki. 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.