Skip to content

Commit

Permalink
chore: Interim update to the release template
Browse files Browse the repository at this point in the history
  • Loading branch information
NickLarsenNZ committed Dec 10, 2024
1 parent 25a19b1 commit a165f0e
Showing 1 changed file with 18 additions and 15 deletions.
33 changes: 18 additions & 15 deletions .github/ISSUE_TEMPLATE/release.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,8 @@ Replace the items in the task lists below with the applicable Pull Requests / Is
```[tasklist]
### Early Pre-release tasks
- [ ] Create a "Post XX.XX release" retro issue (does this need a template? See https://github.com/stackabletech/issues/issues/669)
- [ ] Define product versions to include in the next release
- [ ] [Update and release operator-rs workspace members](https://github.com/stackabletech/operator-rs/issues/new?template=release-workspace-members.md)
- [ ] [Update Rust toolchain of operators](https://github.com/stackabletech/operator-templating/issues/new?template=pre-release.md)
- [ ] [Update Rust dependencies of operators](https://github.com/stackabletech/issues/issues/new?template=pre-release-operator-rust-deps.md)
Expand Down Expand Up @@ -68,20 +70,22 @@ This will not be so crucial with release branches, but is nonetheless sensible a
```[tasklist]
#### Technical tasks
- [ ] Temporarily remove branch protection before pushing the release branches/tags
- [ ] Create release branches for docker-images (see stackable-utils for script to create branches)
- [ ] Create release branch for docker-images (see stackable-utils for script to create branches)
- [ ] Create release tag(s) for docker-images (see stackable-utils for scripts to create tags)
- [ ] Create release branches for operators (see stackable-utils for script to create branches)
- [ ] Create release tag(s) for operators (see stackable-utils for scripts to create tags)
- [ ] Create release tag for stackable-cockpit (optional, highly experimental, requires manual tag creation)
- [ ] Update release version in changelogs on main branches (see stackable-utils for script to do this)
- [ ] Create release branch for demos (see stackable-utils for script to create branches)
- [ ] Generate CRD docs [website](https://crds.stackable.tech/) for the new release by following these [instructions](https://github.com/stackabletech/crddocs)
- [ ] Check (selected) integration tests on the new release branches
- [ ] Run/Check getting started scripts, ensure image pulls for the release works
- [ ] Run/Check demos with dev release and main branch and create draft PR for release-related changes
- [ ] Test `stackablectl` with locally updated (to new release number) `releases.yaml`
- [ ] Update `release.yaml` in https://github.com/stackabletech/release/blob/main/releases.yaml
- [ ] Check that an upgrade can be performed on an existing cluster without data loss.
- [ ] ARM demo and integration testing of some kind
- [ ] [Check and update getting-started script](https://github.com/stackabletech/issues/issues/new?template=TODO-getting-started-scripts.md)
- [ ] [Test demos for the new release](https://github.com/stackabletech/demos/issues/new?template=TODO-release-testing.md)
- [ ] Check that an upgrade can be performed on an existing cluster without data loss (cycling demo)
- [ ] Run all of the test suites
- [ ] OpenShift testing on Rosa <!-- where is that at? -->
```

```[tasklist]
Expand All @@ -94,9 +98,12 @@ This will not be so crucial with release branches, but is nonetheless sensible a
- [ ] Upgrade guide: List dropped supported product versions (if there are some)
- [ ] Upgrade guide: List dropped supported operators (if there are some)
- [ ] Upgrade guide: List supported k8s versions
- [ ] Update version of main documentation repo (antora.yml on the release branch)
- [ ] Update SDP release version in documentation/modules/ROOT/pages/getting-started.adoc
- [ ] Set the release to "Released" in the Feature Tracker and create a new release
- [ ] The team reviews the preview release notes: (structure, wording, xrefs and links, sentences on new lines)
- [ ] Update SDP release version in documentation/modules/ROOT/pages/getting-started.adoc and test the release install command
- [ ] Cut a release branch (see [scripts/make-release-branch.sh](https://github.com/stackabletech/documentation/blob/main/scripts/make-release-branch.sh))
- [ ] Update releases in the playbook (see [scripts/publish-new-version.sh](https://github.com/stackabletech/documentation/blob/main/scripts/publish-new-version.sh))
- [ ] Update antora.yaml version in stackabletech/demos on the release branch - the stackable-utils release-scripts should do this like they do for products and operators.
- [ ] Set the release to "Released" in the Feature Tracker and create a new release (how?)
- [ ] Update the getting-started page in the main docs and check it works with this release: https://github.com/stackabletech/documentation/blob/main/modules/ROOT/pages/getting-started.adoc
```

Expand Down Expand Up @@ -124,12 +131,8 @@ Marketing tasks can now reference published documentation.
```[tasklist]
### Post-release tasks
- [ ] Update the list of supported SDP releases in Jira (ping Jim)
- [ ] Bump Rust version. This can be done [in this file](https://github.com/stackabletech/operator-templating/blob/main/config/rust.yaml) by changing `rust_version` and also for the ubi base image [here](https://github.com/stackabletech/docker-images/blob/main/ubi8-rust-builder/Dockerfile#L25). Please be aware that this action will change it for all repositories at the same time (when merging the templating PRs).
- [ ] Check/bump versions of kube-rs and k8s-openapi (also checking the version of k8s we build against)
- [ ] Check/bump ubi9 base image
- [ ] preflight now checks automatically it's own version and only runs if latest ~~Check/bump preflight~~
- [ ] Openshift certification. Create an issue from this [template](https://github.com/stackabletech/issues/blob/main/.github/ISSUE_TEMPLATE/olm_manifests.md) for the OLM manifests
- [ ] Define product versions to include in the next release
- [ ] Add branch protection to release branches once they are stable
- [ ] Mark any end-of-life releases as such [in the documentation](https://github.com/stackabletech/documentation/blob/f751e7ff7cddacae7d2c6c2c6c1d1c877c7aa11c/antora.yml#L18)
- [ ] Mark any releases older than one year as "end-of-life" [in the documentation](https://github.com/stackabletech/documentation/blob/f751e7ff7cddacae7d2c6c2c6c1d1c877c7aa11c/antora.yml#L18) How? Ask Lars of course. He's good at that stuff.
- [ ] Post XX.XX release retro (use issue created at the start of the process)
- [ ] [Create the next release tracking task](https://github.com/stackabletech/issues/issues/new?template=release.md) (if the date is available)
```

0 comments on commit a165f0e

Please sign in to comment.