Skip to content

📖 Add issue template for release tasks #2608

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions .github/ISSUE_TEMPLATE/new_release.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
---
name: New release
about: "[Only for maintainers] Create an issue to track release activities"
title: Tasks for v<release-tag> release cycle

---

## Tasks

Tasks for a new release `vX.Y.Z` of the Cluster API Provider OpenStack.
For details, see [RELEASE.md](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/RELEASE.md).

- [ ] [When bumping `X` or `Y`] Create a new release branch called `release-X.Y`.
- [ ] [When bumping `X` or `Y`] Add 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)
on the release branch prior to release.
- [ ] Push tag to the repository.
- [ ] Promote the [staging image](https://console.cloud.google.com/cloud-build/builds?project=k8s-staging-capi-openstack) by
adding the new sha=>tag mapping to [images.yaml](https://github.com/kubernetes/k8s.io/blob/main/registry.k8s.io/images/k8s-staging-capi-openstack/images.yaml).
- [ ] Verify that the new draft release looks good and make changes if necessary.
- [ ] Verify that the image was promoted sucessfully.
- [ ] 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".

## Post-release tasks

- [ ] [When bumping `X` or `Y`] Update the [periodic jobs](https://github.com/kubernetes/test-infra/tree/master/config/jobs/kubernetes-sigs/cluster-api-provider-openstack).
Make sure there are periodic jobs for the new release branch, and clean up jobs for branches that are no longer supported.
- [ ] [When bumping `X` or `Y`] Update the [clusterctl upgrade tests](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/test/e2e/suites/e2e/clusterctl_upgrade_test.go)
and the [e2e config](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/test/e2e/data/e2e_conf.yaml)
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.
10 changes: 10 additions & 0 deletions RELEASE.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,8 @@ The content of the release notes differs depending on the type of release, speci

## Process

There is an [issue template](.github/ISSUE_TEMPLATE/new_release.md) to help track release activities.

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`
Expand Down Expand Up @@ -75,6 +77,14 @@ The content of the release notes differs depending on the type of release, speci
1. Ensure that the release image has been promoted.
1. Publish release.

### Post release actions

1. When bumping `X` or `Y` (but not Z or the pre-release suffix), update the [periodic jobs](https://github.com/kubernetes/test-infra/tree/master/config/jobs/kubernetes-sigs/cluster-api-provider-openstack).
Make sure there are periodic jobs for the new release branch, and clean up jobs for branches that are no longer supported.
1. When bumping `X` or `Y` (but not Z or the pre-release suffix), update the [clusterctl upgrade tests](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/test/e2e/suites/e2e/clusterctl_upgrade_test.go) and the [e2e config](https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/test/e2e/data/e2e_conf.yaml)
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.

### Permissions

Releasing requires a particular set of permissions.
Expand Down