Update pylint config docs (#2931)

[etc/vim.git] / docs / contributing / release_process.md

diff --git a/docs/contributing/release_process.md b/docs/contributing/release_process.md
index ae95cd703c9e546509fdc92d9007c5d5173ee0ce..6a4b8680808e028d53e453d3e975506e06a54c92 100644 (file)
--- a/docs/contributing/release_process.md
+++ b/docs/contributing/release_process.md
@@ -3,14 +3,16 @@
 _Black_ has had a lot of work automating its release process. This document sets out to
 explain what everything does and how to release _Black_ using said automation.
 
 _Black_ has had a lot of work automating its release process. This document sets out to
 explain what everything does and how to release _Black_ using said automation.
 

-## Cutting a Relase
+## Cutting a Release

 
 To cut a release, you must be a _Black_ maintainer with `GitHub Release` creation
 access. Using this access, the release process is:
 
 
 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)
 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.
 
 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
 ## Release workflows
 
 All _Blacks_'s automation workflows use GitHub Actions. All workflows are therefore


@@ -70,3 +126,20 @@ to download the executable for their platform and run _Black_ without a
 The created binaries are attached/stored on the associated
 [GitHub Release](https://github.com/psf/black/releases) for download over _IPv4 only_
 (GitHub still does not have IPv6 access 😢).
 The created binaries are attached/stored on the associated
 [GitHub Release](https://github.com/psf/black/releases) for download over _IPv4 only_
 (GitHub still does not have IPv6 access 😢).

+
+## Moving the `stable` tag
+
+_Black_ provides a stable tag for people who want to move along as _Black_ developers
+deem the newest version reliable. Here the _Black_ developers will move once the release
+has been problem free for at least ~24 hours from release. Given the large _Black_
+userbase we hear about bad bugs quickly. We do strive to continually improve our CI too.
+
+### Tag moving process
+
+#### stable
+
+From a rebased `main` checkout:
+
+1. `git tag -f stable VERSION_TAG`
+   1. e.g. `git tag -f stable 21.5b1`
+1. `git push --tags -f`