]> 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:

projects / etc / vim.git / blobdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | inline | side by side
bump sphinx so it works on Python3.10 (#2546)
[etc/vim.git] / docs / contributing / release_process.md
diff --git a/docs/contributing/release_process.md b/docs/contributing/release_process.md
index fadef4bbe3d46a0fcca86b03d5cb4ba2684443af..718ea3dc9a292a59ff7f04a23dccc1ba91272e40 100644 (file)
--- a/docs/contributing/release_process.md
+++ b/docs/contributing/release_process.md
@@ -3,9 +3,9 @@
 _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:
 
 1. Cut a new PR editing `CHANGES.md` to version the latest changes
 access. Using this access, the release process is:
 
 1. Cut a new PR editing `CHANGES.md` to version the latest changes
@@ -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`
vim configuration

Legalese

All content available in this repository is copyright © martin f. krafft, unless otherwise noted.

All files and their content are released under the terms of the Artistic Licence 2.0, unless otherwise noted.

The operator of this repository shall not be held liable for offending content in pages linking to or linked from these page, nor does he endorse their content unless stated otherwise.