From 8b3fc646f6a2bf0cef3ab3ac4a95e76129fe5492 Mon Sep 17 00:00:00 2001
From: "Enrique G. Paredes" <18477+egparedes@users.noreply.github.com>
Date: Thu, 20 Jul 2023 15:23:32 +0200
Subject: [PATCH] docs: Move release documentation to docs/development (#1238)

Extract documentation of the release process from the Contributing guidelines to a new document in the developer documentation folder.
---
 CONTRIBUTING.md                   | 37 -------------------------------
 docs/development/tools/release.md | 31 ++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 37 deletions(-)
 create mode 100644 docs/development/tools/release.md

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 4679647738..537a3b5651 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -171,43 +171,6 @@ Before submitting a pull request, check that it meets the following criteria:
 6. Pick one reviewer and try to contact them directly to let them know about the pull request. If there is no feedback in 24h/48h try to contact them again or pick another reviewer.
 7. Once the pull request has been approved, it should be squash-merged as soon as possible with a meaningful description of the changes. Although it is optional, we encourage the use of the [Conventional Commits][conventional-commits] specification for writing informative and automation-friendly commit messages (_commit types: `build`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `feature`, `style`, `test`_).
 
-## Releasing Process
-
-This section documents the process of releasing new versions of GT4Py and it is only useful to core members of the development team.
-
-Currently, GT4Py releases are published as commit tags in the main GitHub repository (although they will be soon available in TestPyPi and PyPI). To create a new release you should:
-
-1. Make sure all the expected changes (new features, bug fixes, documentation changes, etc.) are already included in the main public branch.
-
-2. Use `bump2version` to update the version number.
-
-   ```bash
-   $ bump2version minor # or patch
-   ```
-
-3. Update the [CHANGELOG.md](CHANGELOG.md) file to document the changes included in the new release. This process can be fully or partially automated if commit messages follow the [Conventional Commits][conventional-commits] convention as suggested in the section about [Pull Request and Merge Guidelines](#pull-request-and-merge-guidelines).
-
-4. Commit the changes with the following commit message:
-
-   ```bash
-   $ git commit -m 'Releasing 0.{M}.{m}.{p} version.'
-   ```
-
-5. Add a new lightweight tag like: `v0.{M}.{m}.{p}`
-
-   ```bash
-   $ git tag v0.{M}.{m}.{p}
-   ```
-
-6. Push the new commit and tag directly to the upstream repo:
-
-   ```bash
-   $ git push upstream
-   $ git push upstream v0.{M}.{m}.{p}
-   ```
-
-7. Go to the GitHub website and verify that the new tag has been successfully created.
-
 ## Tools
 
 As mentioned above, we use several tools to help us write high-quality code. New tools could be added in the future, especially if they do not add a large overhead to our workflow and they bring extra benefits to keep our codebase in shape. The most important ones which we currently rely on are:
diff --git a/docs/development/tools/release.md b/docs/development/tools/release.md
new file mode 100644
index 0000000000..c47d4d7c42
--- /dev/null
+++ b/docs/development/tools/release.md
@@ -0,0 +1,31 @@
+# Releasing Process
+
+This document describes the process of releasing new versions of GT4Py.
+
+Currently, GT4Py releases are published in PyPI (and TestPyPI) and also as commit tags in the main GitHub repository. To create a new release you should:
+
+1. Make sure all the expected changes (new features, bug fixes, documentation changes, etc.) are already included in the `main` public branch.
+
+2. Use **bump2version** to update the version number.
+
+   ```bash
+   $ bump2version minor # or patch
+   ```
+
+3. Update the [CHANGELOG.md](CHANGELOG.md) file to document the changes included in the new release. Note that this step becomes much simpler when commit messages follow the [Conventional Commits][conventional-commits] convention as encouraged in the [Pull Request and Merge Guidelines](CONTRIBUTING.md#pull-request-and-merge-guidelines) section of the contributing guidelines.
+
+4. Commit the changes with the following message:
+
+   ```bash
+   $ git commit -m 'Releasing 0.{M}.{m}.{p} version.'
+   ```
+
+5. On the GitHub website go to _Releases_ and _Draft a new release_. Choose `v0.{M}.{m}.{p}` as tag and select a branch (usually `main`). Follow the style of the previous releases for the title (`GT4Py v0.{M}.{m}.{p}`) and description. Then _Publish release_.
+
+6. Upload distribution package to TestPyPI and quickly test that it works properly.
+
+7. Upload distribution package to PyPI and quickly that test it works properly.
+
+<!-- Reference links -->
+
+[conventional-commits]: https://www.conventionalcommits.org/en/v1.0.0/#summary