Short term release process: address some feedback

* Clarify the problem with merging in the Gitflow model
* Clarify use of "comp" to "competition"
* Remove uncertainty around the auditor and faucet binaries being part of the package
* Remove uncertainty around `NETWORK_VERSION`
* Refine the hotfix process to include `rc.1` pre-release specifier
* Clarify that the Github Release creates a tag

0001-short-term-release-process/0001-release-process-short-term.md

@@ -47,7 +47,7 @@ Release and deployment for next wave:
 
 ### Wave 2
 
-Live for users: 2024-07-09 / 825 people / 11 week comp / comp ends: 2024-09-27
+Live for users: 2024-07-09 / 825 people / 11 week competition / competition ends: 2024-09-27
 
 Three week development/release cycle:
 * Development begins 2024-07-08
@@ -56,7 +56,7 @@ Three week development/release cycle:
 
 ### Wave 3
 
-Live for users: 2024-08-01 / 1000 people / 8 week comp / comp ends: 2024-09-27
+Live for users: 2024-08-01 / 1000 people / 8 week competition / competition ends: 2024-09-27
 
 Three week development/release cycle:
 * Development begins 2024-08-01
@@ -65,7 +65,7 @@ Three week development/release cycle:
 
 ### Wave 4
 
-Live for users: 2024-08-23 / 1000 people / 5 week comp / comp ends: 2024-09-27
+Live for users: 2024-08-23 / 1000 people / 5 week competition / competition ends: 2024-09-27
 
 Three week development/release cycle:
 * Development begins 2024-08-22
@@ -74,7 +74,7 @@ Three week development/release cycle:
 
 ### Wave 5
 
-Live for users: 2024-09-13 / 1000 people / 3 week comp / comp ends: 2024-09-27
+Live for users: 2024-09-13 / 1000 people / 3 week competition / competition ends: 2024-09-27
 
 Three week development/release cycle:
 * Development begins 2024-09-12
@@ -100,9 +100,9 @@ Historically, our team has preferred `git rebase` to `git merge`; however, Gitfl
 supported by using `git merge`. Rebasing is fine before submitting upstream, but Gitflow involves
 merging commits between different branches. Due to the fact that rebasing rewrites the commit
 history, merging between branches can lead to commits that have the same content but different
-hashes. This can make merging more confusing than it needs to be and also cause the commit history
-to be littered with duplicates. The primary option for completing a PR should be to merge it in
-rather than rebase.
+hashes. This can make subsequent, post-rebase merging more confusing than it needs to be and also
+cause the commit history to be littered with duplicates. The primary option for completing a PR
+should be to merge it in rather than rebase.
 
 ## Release Cycle Overview
 
@@ -157,7 +157,7 @@ in more detail.
 All release types will produce a set of binary artifacts, so we'll discuss these first. In Rust,
 crates must use Semantic Versioning. A binary is defined within a crate, and therefore, by default,
 it will also have a Semantic Version; however, it is possible to override the `--version` argument
-on the binary to provide something custom. Our releases currently produce eight binary artifacts. *
+on the binary to provide something custom. Our releases currently produce eight binary artifacts.
 It would be useful if we could refer to these collectively with a single version number and package,
 where the package name would reflect the version number. ** The `--version` argument would identify
 this version number, but also identify the individual component using its Semantic Version. *
@@ -170,7 +170,6 @@ this combined release.
 
 #### Uncertainties
 
-* Should `faucet` and `sn_auditor` be part of a package targeted at users?
 * Should Semantic Versions be dropped from user-facing elements?
 * What are the `X` and `Y` in the version number?
 
@@ -198,7 +197,7 @@ coordinate with users.
 * The release workflow will produce a public `pre-release` on Github, but the crates will *not* be
   published.
 * Manually edit the Github Release to provide the description prepared in the first step.
-* Use the `Launch Network` workflow to deploy the `alpha` binaries to an isolated network. *
+* Use the `Launch Network` workflow to deploy the `alpha` binaries to an isolated network.
 * Announce the availability of the binaries to the community. Users can use `safenode-manager`
   and/or `safeup` with `--version` arguments to obtain the alpha binaries.
 * Perform testing
@@ -213,12 +212,8 @@ coordinate with users.
 * The experiment is over and the branch should be deleted.
 
 The branch is discarded because we don't want the alpha version bumps back in `main`. Crates were
-also not published. The Github Release will function as the historical record of the existence of
-the alpha release.
-
-#### Uncertainties
-
-* Would we need to use the `NETWORK_VERSION` compile-time variable for this?
+also not published. A Github Release always creates a tag, so this will function as the historical
+record of the existence of the alpha release.
 
 ### Release Candidates
 
@@ -304,17 +299,19 @@ throughout the release cycle, although they'd probably more likely be near the b
 
 ### Process
 
-* Create and checkout a `hotfix-YYYY.MM.DD` branch from `stable` and push it to `origin`
-* Create an entry in the changelog that describes the fix
-* Use `release-plz update` to get new version numbers for the crates that the fix applies to
+* Create and checkout a `hotfix-YYYY.MM.DD` branch from `stable` and push it to `origin`.
+* Create an entry in the changelog that describes the fix.
+* Use `release-plz update` to get new version numbers for the crates that the fix applies to.
+* Use a script to apply an `rc.1` pre-release specifier to the bumped crates.
 * Create a `chore(release): hotfix-YYYY.MM.DD` commit with the bumped crates and versions in the
   body of the commit.
 * Fetch this branch from `upstream` to a fork and apply the fix.
 * PR the commit with the fix to the `upstream` branch. This will enable someone to review it.
 * If changes are requested, keep going until those are resolved.
-* Use a workflow to deploy 
-* Deploy the fix to some kind of staging environment to be tested.*
-* When the fix is confirmed to be working, create a PR to merge the branch back into `stable`.
+* Use a workflow to deploy the fix to a dev/staging environment to be tested.*
+* When the fix is confirmed to be working:
+    - Remove the `rc` pre-release specifier
+    - Create a PR to merge the branch back into `stable`
 * Also merge it back into `main`.
 * Perform a stable release at the new version number.*
 * If it's a change to the node, deploy it to production using an upgrade process.