Skip to content
Merged
28 changes: 11 additions & 17 deletions .github/ISSUE_TEMPLATE/02-advanced-issue.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,15 +7,13 @@ assignees: ''

---

# Title

<!--
- Ensure the title is specific and descriptive
- Ensure the PR title is specific and descriptive
- Avoid acronyms if possible
-->

## Description

<!--
- "What" are we trying to achieve
- Briefly describe what this issue aims to achieve
Expand All @@ -25,7 +23,7 @@ Examples:
-->

## Value

<!--
- "Why" do we want to do this
- Clearly define the value this brings to customers or why else it is important if not _directly_ for customers (e.g. internal tooling or improvements, technical debt, ...)
Expand All @@ -38,7 +36,7 @@ Examples:
-->

## Dependencies

<!--
- Consider and name any internal and external dependencies and constraints
- List all known necessary resources (e.g. cluster, customers, people, repositories, libraries...)
Expand All @@ -59,14 +57,14 @@ Examples:
- Marketing / Showcase
- Initial tasks might just be _separate_ research tasks, which, upon completion, lead to more tasks in this task/epic
- When creating the list of tasks make sure to put them in an order and focus on creating minimum marketable features
- This is the _Definition of Done_ which (mostly, exception are marketing tasks) represents the technical "completeness" of a task
- This is the _Definition of Done_ which (mostly, exception are marketing tasks) represents the technical "completeness" of a task

Example:
- Marketing: Prepare a blog post outlining the new CRD versioning support, our policies around CRD versioning and the current versions we do support
-->

## Acceptance Criteria

<!--
- List acceptance criteria
- Define clear objective criteria for when we would consider this issue "Done"
Expand All @@ -80,12 +78,11 @@ Example:
- Traces are exported via OTLP and can be seen in Jaeger (or equivalent trace visualisation tool) (achieves a goal, while only being as prescriptive as necessary)
- CRD versioning is seamlessly integrated into our operators, allowing for the specification of multiple versions within CRDs.
- Backward compatibility is maintained for at least two previous versions of CRDs.
-

-->

## (Information Security) Risk Assessment

<!--
- Outline any information security (this includes cybersecurity) or any other obvious risks and the controls how to mitigate them
- This is relevant for ISO 27001, the Cyber Resilience Act and other standards/norms
Expand All @@ -99,7 +96,6 @@ Example:
- ...
-->


## Accessibility Assessment

<!--
Expand All @@ -109,17 +105,16 @@ Example:
-->

## Quality

<!--
- Outline how this issue will be tested
- Compatibility:
- Try to ensure compatibility with all our supported versions (e.g. Kubernetes, OpenShift, product versions)
- List any potential compatibility issues you're aware of
-->

-->

## Release Notes

<!--
- Write a short sentence or abstract that can go into the release notes
- This way it is also documented for anyone finding _just this_ issue later
Expand All @@ -135,12 +130,11 @@ NOTE: This section is not meant to be displayed, therefore it is in a comment. Y
- [ ] Delete everything that is irrelevant for this particular issue.
- [ ] Add appropriate labels


- There are different types of issues/epics, which might require different subsets (or no) sections of the above
- e.g. "Update product versions"
- e.g. "Implement new feature"
- In the whole issue write out all acronyms that are not industry standard at least once. Example: OpenPolicyAgent (OPA)
- If this is part of another issue please make sure to link the two in both places (parent & child)
- If CRD changes (not necessarily breaking) are required, make sure structs/enums/fields are documented and are rendered properly in the CRD generation tool
- Also see our [Development Philosophy](https://app.nuclino.com/Stackable/Stackable-Handbook/Development-Philosophy-ba280b20-b8cd-4fb6-a863-ff6d8c9f1af2)
-->
-->
2 changes: 1 addition & 1 deletion .github/ISSUE_TEMPLATE/04-pre-release-openshift-tests.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ Part of <https://github.com/stackabletech/issues/issues/TRACKING_ISSUE>

Make sure to run the tests using the following parameters:

```
```plain
TEST_PLATFORM: OpenShift on replicated.com (4.15.0-okd)
GIT_BRANCH_OR_TAG: origin/main
OPERATOR_VERSION: 0.0.0-dev
Expand Down
185 changes: 114 additions & 71 deletions .github/ISSUE_TEMPLATE/06-release.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,118 +4,158 @@ about: This template can be used to track the progress of the SDP
title: "chore(tracking): SDP Release YY.M.X"
labels: ['epic']
assignees: ''

---

<!--
DO NOT REMOVE THIS COMMENT. It is intended for people who might copy/paste from the previous release issue.
This was created by an issue template: https://github.com/stackabletech/issues/issues/new/choose.
-->

# Stackable Release YY.M.X

> [!IMPORTANT]
> Important dates:
>
> - ... - Release planning
> - ... - Lock product versions
> - ... - Final operator-rs release at CoB
> - ... - Begin bumping operator-rs crates in each operator
> - ... - Begin release-day tasks (release branches are cut)
> - ... - Begin release-branching tasks
> - ... - Target release date (marketable)

## Release checklists

Replace the items in the task lists below with the applicable Pull Requests / Issues
> [!TIP]
> Replace the items in the task lists below with the applicable Pull Requests / Issues.

### General Pre-Requisites (before Feature Freeze)
## Early Pre-release tasks

> [!TIP]
> These tasks should be done earlier in the process to lessen the burden at Pre-release time.

```[tasklist]
### Early Pre-release tasks
- [ ] [Create a "Release Retro" issue](https://github.com/stackabletech/issues/issues/new?template=08-release-retro.md)
- [ ] [Create a "Release Retro" issue][epr-1]
- [ ] 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=05-pre-release-operator-rust-deps.md)
- [ ] [Major or Minor Container Images updates](https://github.com/stackabletech/docker-images/issues/new?template=early-pre-release.md)
- [ ] [Patch Container Images updates](https://github.com/stackabletech/docker-images/issues/new?template=early-pre-release.md)
```
- [ ] [Update and release operator-rs workspace members][epr-2]
- [ ] [Update Rust toolchain of operators][epr-3]
- [ ] [Update Rust dependencies of operators][epr-4]
- [ ] [Major or Minor Container Images updates][epr-5]
- [ ] [Patch Container Images updates][epr-5] (Do not reuse the previous issue)
- [ ] Run `niv update` and test via `make run-dev` (operator-templating)

[epr-1]: https://github.com/stackabletech/issues/issues/new?template=08-release-retro.md
[epr-2]: https://github.com/stackabletech/operator-rs/issues/new?template=release-workspace-members.md
[epr-3]: https://github.com/stackabletech/operator-templating/issues/new?template=pre-release.md
[epr-4]: https://github.com/stackabletech/issues/issues/new?template=05-pre-release-operator-rust-deps.md
[epr-5]: https://github.com/stackabletech/docker-images/issues/new?template=early-pre-release.md

## Pre-release

> [!TIP]
> These tasks should be done a week or so before the release date.

```[tasklist]
### Pre-release
- [ ] Run all of the test suites in Jenkins (with all product versions, not just "nightly")
- [ ] [Check and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=03-pre-release-getting-started-scripts.md)
- [ ] [Check and update demo charts](https://github.com/stackabletech/demos/issues/new?template=pre-release-chart-updates.md)
- [ ] [Test demos and upgrade from stable to nightly release](https://github.com/stackabletech/demos/issues/new?template=pre-release-upgrade-testing.md)
- [ ] [Check and update getting-started scripts][pr-1]
- [ ] [Check and update demo charts][pr-2]
- [ ] [Test demo upgrades (stable to nightly)][pr-3]
- [ ] [Test demos from scratch (nightly)][pr-4]
- [ ] Ensure integration tests are successful on OpenShift (run with `--test-suite openshift` against Replicated OKD)
- [ ] Check stackable-utils scripts in dry-run mode work
```
- [ ] Check [stackable-utils] scripts in dry-run mode work
- [ ] Search for open issues labeled with [scheduled-for/YY.M.X][pr-5]

### Other Pre-Requisites (before Feature Freeze)
[pr-1]: https://github.com/stackabletech/issues/issues/new?template=03-pre-release-getting-started-scripts.md
[pr-2]: https://github.com/stackabletech/demos/issues/new?template=pre-release-chart-updates.md
[pr-3]: https://github.com/stackabletech/demos/issues/new?template=pre-release-upgrade-testing.md
[pr-4]: https://github.com/stackabletech/demos/issues/new?template=pre-release-from-scratch-testing.md
[pr-5]: https://github.com/search?q=org%3Astackabletech+label%3Ascheduled-for%2FYY.M.X&type=issues&state=open

Search for open issues labeleded with [`scheduled-for/YY.M.X`](https://github.com/search?q=org%3Astackabletech+label%3Ascheduled-for%2FYY.M.X&type=issues&state=open)
## Release branching

```[tasklist]
### Other release-specific pre-requisites
- [ ] Run `niv update` and test via `make run-dev` (operator-templating)
```
> [!CAUTION]
> A small change freeze is required until these tasks have been completed.

### Feature freeze
> [!TIP]
> See [stackable-utils] for script to create tags and update changelogs.

This will not be so crucial with release branches, but is nonetheless sensible as it will make it easier to cherry-pick any release-related bugfixes from main into the release branch.
- [ ] Create release branch for docker-images
- [ ] Create release branches for operators
- [ ] Create release branch for demos
- [ ] _Wait for images to be built before proceeding_

### End of the release cycle (Release day)
## Release candidate testing

> [!WARNING]
> To be discussed during the on-site.
>
> Getting started scripts use particular product versions (this would have been updated in the
> early-pre-release stage), however, at this point in time, the images will be tagged with an rcX
> tag.

<!--

> [!TIP]
> As issues are discovered, they can be fixed on the `main` branch, and cherry-picked into the release branch.
>
> Please ensure the changelog is updated and correct for the release after cherry-picking changes.
> Please also keep PR links as they are in `main` (do not update them for the cherry-picked PR).

```[tasklist]
#### Technical tasks
- [ ] Create release branch for docker-images (see stackable-utils for script to create branches)
- [ ] Create release branches for operators (see stackable-utils for script to create branches)
- [ ] Create release branch for demos (see stackable-utils for script to create branches)
- [ ] _Wait for images to be built_
- [ ] [Check and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=07-release-getting-started-scripts.md) for the Release Candidate
- [ ] [Test demos and upgrade from previous to this release](https://github.com/stackabletech/demos/issues/new?template=release-upgrade-testing.md) for Release Candidate (only fresh install)
- [ ] Create release tag(s) for docker-images (see stackable-utils for scripts to create tags)
- [ ] Create release tag(s) for operators (see stackable-utils for scripts to create tags)
- [ ] Update release version in changelogs on main branches (see stackable-utils for script to do this)
- [ ] Generate CRD docs [website](https://crds.stackable.tech/) for the new release by following these [instructions](https://github.com/stackabletech/crddocs)

-->

## Release tagging

> [!TIP]
> See [stackable-utils] for script to create tags and update changelogs.

- [ ] Create release tag(s) for docker-images
- [ ] Create release tag(s) for operators
- [ ] Update release version in changelogs on main branches
- [ ] _Wait for images to be built before proceeding_
- [ ] 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 and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=07-release-getting-started-scripts.md)
- [ ] [Test demos and upgrade from previous to this release](https://github.com/stackabletech/demos/issues/new?template=release-upgrade-testing.md)
- [ ] Update [release.yaml](https://github.com/stackabletech/release/blob/main/releases.yaml)
- [ ] Release stackablectl

## Release verification

> [!TIP]
> These tasks do not block the Documentation tasks below and can be done concurrently.

- [ ] [Check getting-started scripts][rv-1]
- [ ] [Test demos from scratch (YY.M.X)][rv-2]
- [ ] Check that an upgrade can be performed on an existing cluster without data loss (cycling demo)
- [ ] Run all integration tests (for both `x86_64` and ~`aarch64`~ (defer aarch64 until interu is used))
- [ ] Ensure integration tests are successful on OpenShift (run with `--test-suite openshift` against Replicated OKD)
- [ ] Release stackablectl
```

[rv-1]: https://github.com/stackabletech/issues/issues/new?template=07-release-getting-started-scripts.md
[rv-2]: https://github.com/stackabletech/demos/issues/new?template=release-upgrade-testing.md

## Documentation tasks

> [!TIP]
> Name the release-notes branch `docs/release-notes-YY.M.X` so that the link below takes you directly to the [Pull Request template][docs-pr-template].

[docs-pr-template]: https://github.com/stackabletech/documentation/tree/main/.github/PULL_REQUEST_TEMPLATE/release-notes.md&title=chore(tracking):%20Release%20Notes%20for%20SDP%20YY.M.X

```[tasklist]
#### Documentation tasks
- [ ] Generate CRD docs [website][dt-1] for the new release by following these [instructions][dt-2]
- [ ] Create a stackabletech/documentation branch called `docs/release-notes-YY.M.X`
- [ ] Compile list of new product features in newly supported versions for the YY.M.X release (for the blog post)
- [ ] Begin writing the release notes with the [Pull Request template](https://github.com/stackabletech/documentation/compare/main...docs/release-notes-YY.M.X?template=release-notes.md&title=chore(tracking):%20Release%20Notes%20for%20SDP%20YY.M.X)
- [ ] Begin writing the release notes with the [Pull Request template][dt-3]
- [ ] 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))
- [ ] Cut a release branch (see [scripts/make-release-branch.sh][dt-4])
- [ ] Update releases in the playbook (see [scripts/publish-new-version.sh][dt-5])
- [ ] Remove any references to HEAD and main from the Antora playbooks on the release branch (replace with the release branch)
- [ ] 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 (ping @lfrancke)
- [ ] 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
```
- [ ] Update the [getting-started page][dt-6] in the main docs and check it works with this release

[dt-1]: https://crds.stackable.tech/
[dt-2]: https://github.com/stackabletech/crddocs
[dt-3]: https://github.com/stackabletech/documentation/compare/main...docs/release-notes-YY.M.X?template=release-notes.md&title=chore(tracking):%20Release%20Notes%20for%20SDP%20YY.M.X
[dt-4]: https://github.com/stackabletech/documentation/blob/main/scripts/make-release-branch.sh
[dt-5]: https://github.com/stackabletech/documentation/blob/main/scripts/publish-new-version.sh
[dt-6]: https://github.com/stackabletech/documentation/blob/main/modules/ROOT/pages/getting-started.adoc
[docs-pr-template]: https://github.com/stackabletech/documentation/tree/main/.github/PULL_REQUEST_TEMPLATE/release-notes.md&title=chore(tracking):%20Release%20Notes%20for%20SDP%20YY.M.X

Marketing tasks can now reference published documentation.
## Marketing tasks

> [!NOTE]
> Marketing material can now reference published documentation.

```[tasklist]
#### Marketing tasks
- [ ] Write marketing / customer oriented release summary to be published in the marketing channels
- [ ] Update the homepage banner (as long as we have it) to point to the new release
- [ ] Write a blogpost / news article announcing the new release (optional)
Expand All @@ -127,19 +167,22 @@ Marketing tasks can now reference published documentation.
- [ ] Post an announcement in the GitHub [Discussions Announcement forum](https://github.com/stackabletech/community/discussions/categories/announcements) and make it a pinned discussion while at the same time removing the old pinned thread
- [ ] Post an announcement in Discord
- [ ] Post an announcement on DOK Community in the #be-shameless Channel (Ping Lars or Jim)
- [ ] Post an announcement via OSBA (Ping Lars, info@osb-alliance.com)
- [ ] Post an announcement via OSBA (Ping Lars, <mailto:info@osb-alliance.com>)
- [ ] Send announcement to Kubernetes Podcast (Ping Lars)
- [ ] Send announcement to Heiser
- [ ] Ping the stackable-ionos-tech channel or anyone responsible once all tags are created
```

```[tasklist]
#### Post-release tasks
## Post-release tasks

- [ ] Test demo upgrades, which were skipped in the previous testing (optional)
- [ ] Update the list of supported SDP releases in Jira (ping Jim)
- [ ] 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
- [ ] Mark any releases older than one year as "end-of-life" [in the documentation](https://github.com/stackabletech/documentation/blob/f751e7ff7cddacae7d2c6c2c6c1d1c877c7aa11c/antora.yml#L18) (update antora.yaml on the applicable branches).
- [ ] Post YY.M.X release retro (use issue created at the start of the process)
- [ ] Update the release tracking template (optional)
- [ ] [Create the next release tracking task](https://github.com/stackabletech/issues/issues/new?template=06-release.md) (if the date is available)
```
- [ ] Update the list of supported SDP releases in Jira (ping @Jimvin)
- [ ] Openshift certification. [Create an issue][pt-1] to track the creation of the OLM manifests
- [ ] Mark any releases older than one year as "end-of-life" in the documentation (update [antora.yaml][pt-2] on the applicable branches).
- [ ] _Link to release retro issue (use issue created at the start of the process)_
- [ ] Update the release tracking templates (optional)
- [ ] [Create the next release tracking task][pt-3] (if the date is available)

[pt-1]: https://github.com/stackabletech/issues/issues/new?template=09-olm_manifests.md
[pt-2]: https://github.com/stackabletech/documentation/blob/f751e7ff7cddacae7d2c6c2c6c1d1c877c7aa11c/antora.yml#L18
[pt-3]: https://github.com/stackabletech/issues/issues/new?template=06-release.md
[stackable-utils]: https://github.com/stackabletech/stackable-utils/blob/main/release/README.md
Loading