Document the new release procedure (#33)

* Document the new release procedure
* Clarify why pre-release is needed
* Clarify how many artifacts we expect

Author: isuruf

README.md

@@ -60,15 +60,16 @@ bash build_miniforge.sh
 
 To release a new version of Miniforge:
 
-- Open a new PR.
-- Edit [`Miniforge3/construct.yaml`](./Miniforge3/construct.yaml).
-  - Update the `version` tag to: `$CONDA_VERSION-$BUILD_NUMBER`. For example, `4.7.11-0`.
-  - Update `conda` version in the `specs` section to `$CONDA_VERSION`.
-  - Update `python` version in the `specs` section to the Python version used in [Miniconda](https://repo.anaconda.com/miniconda/).
-- Once CI is happy, merge into `master`.
-- Tag `HEAD` to `$CONDA_VERSION-$BUILD_NUMBER` and push the tag:
-  - `git tag $CONDA_VERSION-$BUILD_NUMBER`
-  - `git push origin master --tags`
+- Make a new pre-release on GitHub with name `$CONDA_VERSION-$BUILD_NUMBER`
+- Wait until all artifacts are uploaded by CI
+  - For each build, we upload 3 artifacts
+    1. One installer with the version name
+    2. One installer without the version name
+    3. The SHA256
+  - At the time of writing, the is a sum of 24 artifacts, and with the two sources, we expect a grand total of 26 artifacts.
+- Mark the pre-release as a release
+
+NOTE: using a pre-release is important to make sure the latest links work.
 
 ## License