]> git.madduck.net Git - etc/vim.git/blobdiff - docs/contributing/release_process.md

madduck's git repository

Every one of the projects in this repository is available at the canonical URL git://git.madduck.net/madduck/pub/<projectpath> — see each project's metadata for the exact URL.

All patches and comments are welcome. Please squash your changes to logical commits before using git-format-patch and git-send-email to patches@git.madduck.net. If you'd read over the Git project's submission guidelines and adhered to them, I'd be especially grateful.

SSH access, as well as push access can be individually arranged.

If you use my repositories frequently, consider adding the following snippet to ~/.gitconfig and using the third clone URL listed for each project:

[url "git://git.madduck.net/madduck/"]
  insteadOf = madduck:

Top PyPI Packages: Use 30-days data, 365 is no longer available (#2995)
[etc/vim.git] / docs / contributing / release_process.md
index 718ea3dc9a292a59ff7f04a23dccc1ba91272e40..6a4b8680808e028d53e453d3e975506e06a54c92 100644 (file)
@@ -8,9 +8,11 @@ explain what everything does and how to release _Black_ using said automation.
 To cut a release, you must be a _Black_ maintainer with `GitHub Release` creation
 access. Using this access, the release process is:
 
-1. Cut a new PR editing `CHANGES.md` to version the latest changes
-   1. Example PR: https://github.com/psf/black/pull/2192
-   2. Example title: `Update CHANGES.md for XX.X release`
+1. Cut a new PR editing `CHANGES.md` and the docs to version the latest changes
+   1. Remove any empty sections for the current release
+   2. Add a new empty template for the next release (template below)
+   3. Example PR: [#2616](https://github.com/psf/black/pull/2616)
+   4. Example title: `Update CHANGES.md for XX.X release`
 2. Once the release PR is merged ensure all CI passes
    1. If not, ensure there is an Issue open for the cause of failing CI (generally we'd
       want this fixed before cutting a release)
@@ -32,6 +34,60 @@ access. Using this access, the release process is:
 If anything fails, please go read the respective action's log output and configuration
 file to reverse engineer your way to a fix/soluton.
 
+## Changelog template
+
+Use the following template for a clean changelog after the release:
+
+```
+## Unreleased
+
+### Highlights
+
+<!-- Include any especially major or disruptive changes here -->
+
+### Style
+
+<!-- Changes that affect Black's stable style -->
+
+### Preview style
+
+<!-- Changes that affect Black's preview style -->
+
+### _Blackd_
+
+<!-- Changes to blackd -->
+
+### Configuration
+
+<!-- Changes to how Black can be configured -->
+
+### Documentation
+
+<!-- Major changes to documentation and policies. Small docs changes
+     don't need a changelog entry. -->
+
+### Integrations
+
+<!-- For example, Docker, GitHub Actions, pre-commit, editors -->
+
+### Output
+
+<!-- Changes to Black's terminal output and error messages -->
+
+### Packaging
+
+<!-- Changes to how Black is packaged, such as dependency requirements -->
+
+### Parser
+
+<!-- Changes to the parser or to version autodetection -->
+
+### Performance
+
+<!-- Changes that improve Black's performance. -->
+
+```
+
 ## Release workflows
 
 All _Blacks_'s automation workflows use GitHub Actions. All workflows are therefore