Skip to content

Commit

Permalink
Merge pull request #373 from salasberryfin/add-new-post-release-actio…
Browse files Browse the repository at this point in the history
…n-to-release-docs

📖 docs: add pre-release actions to release guide
  • Loading branch information
salasberryfin authored Aug 27, 2024
2 parents 2acd8e4 + 66b5af9 commit a8256cc
Showing 1 changed file with 39 additions and 1 deletion.
40 changes: 39 additions & 1 deletion docs/release.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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.

0 comments on commit a8256cc

Please sign in to comment.