Merge pull request #373 from salasberryfin/add-new-post-release-actio…

…n-to-release-docs

📖 docs: add pre-release actions to release guide

docs/release.md

@@ -47,6 +47,44 @@ git push upstream ${RELEASE_TAG}
 
 This will trigger a [release GitHub action](https://github.com/rancher/cluster-api-provider-rke2/blob/main/.github/workflows/release.yml) that creates a release with RKE2 provider components.
 
+## Tasks
+
+### Prepare main branch for development of the new release
+
+The goal of this task is to bump the versions on the main branch so that the upcoming release version is used for e.g. local development and e2e tests. We also modify tests so that they are testing the previous release.
+
+This comes down to changing occurrences of the old version to the new version, e.g. v1.5 to v1.6, and preparing `metadata.yaml` for a future release version:
+
+#### 1. Update E2E tests
+
+Existing E2E tests that point to a specific version need to be updated to use the new version instead.
+
+1. Add a future release to the list of providers in `test/e2e/config/e2e_conf.yaml` following the format used for previous versions. This will be used as a fake provider version for testing the current state of the repository instead of the actual GitHub release.
+2. Update bootstrap/control plane versions* inside function `initUpgradableBootstrapCluster` in `test/e2e/e2e_suite_test.go`.
+3. Edit upgrade test* in `test/e2e/e2e_upgrade_test.go`.
+
+*To maintain the upgrade test concise and clean, and avoid a growing list of versions, it is required to maintain N-1 minor as a starting version (e.g. if releasing version v4.x, starting version is v3.x and the upgrade is as follows: v3.x -> v4.x).
+
+
+#### 2. Add future version to `metadata.yaml`. For example, if `v0.5` was just released, we add `v0.6` to the list of `releaseSeries`:
+```
+apiVersion: clusterctl.cluster.x-k8s.io/v1alpha3
+kind: Metadata
+releaseSeries:
+  - major: 0
+    minor: 1
+    contract: v1beta1
+  - major: 0
+    minor: 2
+    contract: v1beta1
+  ...
+  ...
+  ...
+  - major: x
+    minor: x
+    contract: x
+```
+
 ## Versioning
 
 Cluster API Provider RKE2 follows [semantic versioning](https://semver.org/) specification.
@@ -96,4 +134,4 @@ The release-X branches contain stable, backwards compatible code. On every major
 Cluster API Provider RKE2 maintains the most recent release/releases for all supported APIs. Support for this section refers to the ability to backport and release patch versions; [backport policy](#backporting) is defined above.
 
 - The API version is determined from the GroupVersion defined in the top-level `bootstrap/api/` and `controlplane/api/` packages.
-- For the current stable API version (v1beta1) we support the two most recent minor releases; older minor releases are immediately unsupported when a new major/minor release is available.
+- For the current stable API version (v1beta1) we support the two most recent minor releases; older minor releases are immediately unsupported when a new major/minor release is available.