| name | New release |
|---|---|
| about | [Only for maintainers] Create an issue to track release activities |
| title | Tasks for v<release-tag> release cycle |
Tasks for a new release vX.Y.Z of the Cluster API Provider OpenStack.
For details, see RELEASE.md.
These tasks must be completed for alpha/beta releases.
- [When bumping
XorY] Add a new entry to metadata.yaml as described in the CAPI book on the release branch prior to release.
The first release candidate (-rc.0) will trigger the creation of the release branch.
Once this is done, complete the following tasks:
- [When bumping
XorY] Add an entry for the new release branch to depandabot.yml. - [When bumping
XorY] Add an entry for the new release branch to security-scan.yaml.
These tasks must be done for each release and pre-release.
- Create the PR after generating release notes according to RELEASE.md. Verify that the release PR looks good and make changes if necessary. When this PR is merged, release automation will push the tag to upstream and create a draft release.
- Promote the staging image by adding the new sha=>tag mapping to images.yaml.
- Verify that the new draft release looks good.
- Verify that the image was promoted sucessfully.
docker run --rm registry.k8s.io/capi-openstack/capi-openstack-controller:vX.Y.Z --version
- Publish the release. Mark the release as "latest" if it is the most recent minor release. E.g. if both v1.1 and v1.2 are supported with patch releases, then only v1.2.z should be marked as "latest".
These tasks can be completed after a release candidate (and branch) is done, or after the final release is out.
- [When bumping
XorY] Update the periodic jobs. Make sure there are periodic jobs for the new release branch, and clean up jobs for branches that are no longer supported. - [When bumping
XorY] Update the clusterctl upgrade tests and the e2e config to include the new release branch. It is also a good idea to update the Cluster API versions we test against and to clean up older versions that we no longer want to test.