docs: document the process of creating a release

It is important to create a guide on how a new version is created, document
the process and assist the maintainer with an ordered list of tasks that
must be performed.

Close #389.

Signed-off-by: Claudio André <dev@claudioandre.slmail.me>

CONTRIBUTING.md

@@ -171,23 +171,6 @@ git merge --ff-only <branch>
 git push -u origin main
 ```
 
-When releasing a new version, create a signed tag, then access and use the GitHub GUI as usual:
-
-```bash
-# E.g., for a rolling release in Oct 2023, the <tag> value should be rolling-2310
-git tag <tag> -m "release: <tag> $(date +%Y%m%d)"
-git tag --verify <tag>
-git push --tags
-```
-
-To create signed GitHub releases:
-
-```bash
-# Create a release
-# Download the tarball <name>.tar.gz generated by GitHub, then
-gpg --armor --detach-sign --output Digitally-signed.tar.gz.asc THE-DOWNLOADED-TARBALL-RELEASE-FILE.tar.gz
-```
-
 ## License
 
 The content of this repository is released under GNU GPL v2.

docs/release-process.md

@@ -0,0 +1,64 @@
+# The Release Process
+
+- When releasing, create signed commits and tags;
+  - You will need to use the CLI, but then just access and use the GitHub GUI as usual:
+- To sign the source code:
+
+  ```bash
+  # Create a release
+  # Download the tarball <name>.tar.gz generated by GitHub, then
+  gpg --armor --detach-sign --output Digitally-signed.tar.gz.asc THE-DOWNLOADED-TARBALL-RELEASE-FILE.tar.gz
+  ```
+
+- Upload the Digitally-signed.tar.gz.asc file to the newly created GitHub release.
+
+The list of tasks:
+
+- [ ] Ensure the `release` branch is up to date and clean;
+  - The `release` branch is a copy of the `main` branch;
+- [ ] Add a new commit to the `release` branch;
+  - This is the "release commit".
+- [ ] The `main` and `release` branches are synchronized;
+  - `git checkout release; git pull --rebase origin main`
+  - Only amend the "release commit"; we will use a fast forward merge;
+  - Any other changes to the source code from this point onwards must cause a restart from the beginning.
+- [ ] Update all release-related documentation;
+  - Amend and push the "release commit";
+- [ ] Run all CI (standard, macOS, Gitlab, Solaris and Android); [1]
+  - Confirm that all builds are ok;
+- [ ] Build the snap (use Launchpad); [2]
+  - Confirm that all builds are ok;
+- [ ] Build the Docker image (bleeding or latest); [3]
+  - Confirm that all builds are ok;
+- [ ] Update versions of the software used for packaging (in deploy/readme and CI/readme); [4]
+  - Amend and push the "release commit";
+- [ ] Release to snap store and flathub;
+
+The "release commit" is ready.
+
+- [ ] Add a new commit to update the logs in /Releases/[RELEASE]; [5]
+- [ ] Update all logs;
+  - Amend and push the "logs commit";
+
+The "logs commit" is ready.
+
+- [ ] Merge the PR; [6]
+  - Go to the `main` branch and use a fast forward merge;
+  - `git checkout main; git merge --ff-only release`.
+- [ ] Create the release tag; [7]
+  - `git tag <tag> -m "release: <tag> $(date +%Y%m%d)"`.
+- [ ] Update the repository;
+  - `git push -u origin main`.
+  - `git push --tags`.
+- [ ] Release the GitHub release.
+  - Use Azure to release it.
+
+Footnotes:
+
+1. all files that will be in the GitHub release are ready to go. still need to be released;
+2. all snap packages are ready to go. still need to be released;
+3. the Docker image has been released;
+4. manual task of accessing logs and copying information;
+5. update and run get-files.sh;
+6. the release itself is based on the last commit and its git tag.
+7. e.g., for a rolling release in Oct 2023, the `<tag>` value should be rolling-2310