🌱 Update RELEASE.md process for release branches

Author: mdbooth

RELEASE.md

@@ -14,35 +14,64 @@
    example, in the `v0.2.0` release, the container image location is
    `us.gcr.io/k8s-artifacts-prod/capi-openstack/capi-openstack-controller:v0.2.0`
 
+## Version number
+
+A release version string is: `vX.Y.Z`.
+
+A pre-release version string additionally has a suffix:
+- `alpha` for an alpha release
+- `beta` for a beta release
+- `rc` for a release candidate
+and an additional index starting at 0. This takes the form: `vX.Y.Z-[suffix].N`. e.g. the first release candidate prior
+to version 1.2.3 would be called `v1.2.3-rc.0`.
+
+It is recommended to create at least one release candidate when bumping `X` or `Y`.
+
 ## Process
 
-1. Make sure your repo is clean by git's standards.
-1. Make sure you are on the correct branch (`main` for the current release and `release-0.x` for older releases).
+1. Make sure your repo is clean by git's standards. It is recommended to use a fresh checkout.
+1. When bumping `X` or `Y` (but not Z or the pre-release suffix) in the release version you must create a new release branch called `release-X.Y`.
+   > NOTE: `upstream` should be the name of the remote pointing to `github.com/kubernetes-sigs/cluster-api-provider-openstack`
+    - git checkout main
+    - git pull
+    - git checkout -b release-`X`.`Y`
+    - git push --set-upstream `upstream`
+1. When bumping `X` or `Y` (but not Z or the pre-release suffix) in the release version, ensure you have added a new
+   entry to [metadata.yaml](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/metadata.yaml)
+   as [described in the CAPI book](https://cluster-api.sigs.k8s.io/clusterctl/provider-contract.html#metadata-yaml), and
+   that this has been committed to the release branch prior to release.
+1. Make sure you are on the correct release branch: `release-X.Y`
 1. Set an environment variable with the version, e.g.:
-    - `VERSION=v0.4.0`
+    - `VERSION=v0.6.0`
 1. Create an annotated tag
     - `git tag -s -a $VERSION -m $VERSION`.
 1. Push the tag to the GitHub repository:
    > NOTE: `upstream` should be the name of the remote pointing to `github.com/kubernetes-sigs/cluster-api-provider-openstack`
     - `git push upstream $VERSION`
-1. Run `make release` to build artifacts (the image is automatically built by CI)
+
+   This will cause the image to be automatically built by CI and pushed to the staging repository. As this only builds
+   the image, it only takes a few minutes.
 1. Follow the [image promotion process](https://github.com/kubernetes/k8s.io/tree/main/k8s.gcr.io#image-promoter) to promote the image from the staging repo to `k8s.gcr.io/capi-openstack`.
    The staging repository can be inspected at https://console.cloud.google.com/gcr/images/k8s-staging-capi-openstack/GLOBAL. Be
    sure to choose the top level `capi-openstack-controller`, which will provide the multi-arch manifest, rather than one for a specific architecture.
    The image build logs are available at [Cloud Build](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-capi-openstack).
    Add the new sha=>tag mapping to the [images.yaml](https://github.com/kubernetes/k8s.io/edit/main/k8s.gcr.io/images/k8s-staging-capi-openstack/images.yaml) (use the sha of the image with the corresponding tag). The PR to update the [images.yaml](https://github.com/kubernetes/k8s.io/edit/main/k8s.gcr.io/images/k8s-staging-capi-openstack/images.yaml) must be approved in the [OWNERS](https://github.com/kubernetes/k8s.io/blob/main/k8s.gcr.io/images/k8s-staging-capi-openstack/OWNERS) file and merged.
-1. Create a draft release in GitHub based on the tag created above
+1. Run `make release` to build artifacts to be attached to the GitHub release.
 1. Generate and finalize the release notes and add them to the draft release:
     - Run `make release-notes` to gather changes since the last revision. If you need to specify a specific tag to look for changes
       since, use `make release-notes RELEASE_NOTES_ARGS="--from <tag>"`.
     - Pay close attention to the `## :question: Sort these by hand` section, as it contains items that need to be manually sorted.
+1. Create a draft release in GitHub based on the tag created above
+    - Name the release `Release [VERSION]` where VERSION is the full version string.
+    - For a pre-release, ensure you check `This is a pre-release` in GitHub when creating the release.
+    - Add the release notes generated above as the release description.
 1. Attach the following files to the draft release:
     - `./out/infrastructure-components.yaml`
     - `./out/cluster-template.yaml`
     - `./out/cluster-template-external-cloud-provider.yaml`
     - `./out/cluster-template-without-lb.yaml`
     - `./out/metadata.yaml`
-1.  Publish release. Use the pre-release option for release candidate or beta versions.
+1.  Publish release.
 
 ### Permissions