Formalise style preference description (#2818)

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

diff --git a/docs/contributing/release_process.md b/docs/contributing/release_process.md
index fadef4bbe3d46a0fcca86b03d5cb4ba2684443af..9ee7dbc607c2d881fcab5546d52400bb7736a76b 100644 (file)
--- a/docs/contributing/release_process.md
+++ b/docs/contributing/release_process.md
@@ -3,13 +3,13 @@
 _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 realease, you must be a _Black_ maintainer with `GitHub Release` creation
+To cut a release, you must be a _Black_ maintainer with `GitHub Release` creation

 access. Using this access, the release process is:
 
 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
+1. Cut a new PR editing `CHANGES.md` and the docs to version the latest changes
+   1. Example PR: [#2616](https://github.com/psf/black/pull/2616)

    2. 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
    2. 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


@@ -70,3 +70,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`