You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/ISSUE_TEMPLATE/02-advanced-issue.md
+11-17
Original file line number
Diff line number
Diff line change
@@ -7,15 +7,13 @@ assignees: ''
7
7
8
8
---
9
9
10
-
# Title
11
-
12
10
<!--
13
-
- Ensure the title is specific and descriptive
11
+
- Ensure the PR title is specific and descriptive
14
12
- Avoid acronyms if possible
15
13
-->
16
14
17
15
## Description
18
-
16
+
19
17
<!--
20
18
- "What" are we trying to achieve
21
19
- Briefly describe what this issue aims to achieve
@@ -25,7 +23,7 @@ Examples:
25
23
-->
26
24
27
25
## Value
28
-
26
+
29
27
<!--
30
28
- "Why" do we want to do this
31
29
- 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, ...)
@@ -38,7 +36,7 @@ Examples:
38
36
-->
39
37
40
38
## Dependencies
41
-
39
+
42
40
<!--
43
41
- Consider and name any internal and external dependencies and constraints
44
42
- List all known necessary resources (e.g. cluster, customers, people, repositories, libraries...)
@@ -59,14 +57,14 @@ Examples:
59
57
- Marketing / Showcase
60
58
- Initial tasks might just be _separate_ research tasks, which, upon completion, lead to more tasks in this task/epic
61
59
- When creating the list of tasks make sure to put them in an order and focus on creating minimum marketable features
62
-
- This is the _Definition of Done_ which (mostly, exception are marketing tasks) represents the technical "completeness" of a task
60
+
- This is the _Definition of Done_ which (mostly, exception are marketing tasks) represents the technical "completeness" of a task
63
61
64
62
Example:
65
63
- Marketing: Prepare a blog post outlining the new CRD versioning support, our policies around CRD versioning and the current versions we do support
66
64
-->
67
65
68
66
## Acceptance Criteria
69
-
67
+
70
68
<!--
71
69
- List acceptance criteria
72
70
- Define clear objective criteria for when we would consider this issue "Done"
@@ -80,12 +78,11 @@ Example:
80
78
- 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)
81
79
- CRD versioning is seamlessly integrated into our operators, allowing for the specification of multiple versions within CRDs.
82
80
- Backward compatibility is maintained for at least two previous versions of CRDs.
83
-
-
84
81
85
82
-->
86
83
87
84
## (Information Security) Risk Assessment
88
-
85
+
89
86
<!--
90
87
- Outline any information security (this includes cybersecurity) or any other obvious risks and the controls how to mitigate them
91
88
- This is relevant for ISO 27001, the Cyber Resilience Act and other standards/norms
@@ -99,7 +96,6 @@ Example:
99
96
- ...
100
97
-->
101
98
102
-
103
99
## Accessibility Assessment
104
100
105
101
<!--
@@ -109,17 +105,16 @@ Example:
109
105
-->
110
106
111
107
## Quality
112
-
108
+
113
109
<!--
114
110
- Outline how this issue will be tested
115
111
- Compatibility:
116
112
- Try to ensure compatibility with all our supported versions (e.g. Kubernetes, OpenShift, product versions)
117
113
- List any potential compatibility issues you're aware of
118
-
-->
119
-
114
+
-->
120
115
121
116
## Release Notes
122
-
117
+
123
118
<!--
124
119
- Write a short sentence or abstract that can go into the release notes
125
120
- This way it is also documented for anyone finding _just this_ issue later
@@ -135,12 +130,11 @@ NOTE: This section is not meant to be displayed, therefore it is in a comment. Y
135
130
- [ ] Delete everything that is irrelevant for this particular issue.
136
131
- [ ] Add appropriate labels
137
132
138
-
139
133
- There are different types of issues/epics, which might require different subsets (or no) sections of the above
140
134
- e.g. "Update product versions"
141
135
- e.g. "Implement new feature"
142
136
- In the whole issue write out all acronyms that are not industry standard at least once. Example: OpenPolicyAgent (OPA)
143
137
- If this is part of another issue please make sure to link the two in both places (parent & child)
144
138
- If CRD changes (not necessarily breaking) are required, make sure structs/enums/fields are documented and are rendered properly in the CRD generation tool
145
139
- Also see our [Development Philosophy](https://app.nuclino.com/Stackable/Stackable-Handbook/Development-Philosophy-ba280b20-b8cd-4fb6-a863-ff6d8c9f1af2)
> These tasks should be done a week or so before the release date.
48
51
49
-
```[tasklist]
50
-
### Pre-release
51
52
-[ ] Run all of the test suites in Jenkins (with all product versions, not just "nightly")
52
-
- [ ] [Check and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=03-pre-release-getting-started-scripts.md)
53
-
- [ ] [Check and update demo charts](https://github.com/stackabletech/demos/issues/new?template=pre-release-chart-updates.md)
54
-
- [ ] [Test demos and upgrade from stable to nightly release](https://github.com/stackabletech/demos/issues/new?template=pre-release-upgrade-testing.md)
53
+
-[ ][Check and update getting-started scripts][pr-1]
54
+
-[ ][Check and update demo charts][pr-2]
55
+
-[ ][Test demo upgrades (stable to nightly)][pr-3]
56
+
-[ ][Test demos from scratch (nightly)][pr-4]
55
57
-[ ] Ensure integration tests are successful on OpenShift (run with `--test-suite openshift` against Replicated OKD)
56
-
- [ ] Check stackable-utils scripts in dry-run mode work
57
-
```
58
+
-[ ] Check [stackable-utils] scripts in dry-run mode work
59
+
-[ ] Search for open issues labeled with [scheduled-for/YY.M.X][pr-5]
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)
67
+
## Release branching
62
68
63
-
```[tasklist]
64
-
### Other release-specific pre-requisites
65
-
- [ ] Run `niv update` and test via `make run-dev` (operator-templating)
66
-
```
69
+
> [!CAUTION]
70
+
> A small change freeze is required until these tasks have been completed.
67
71
68
-
### Feature freeze
72
+
> [!TIP]
73
+
> See [stackable-utils] for script to create tags and update changelogs.
69
74
70
-
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.
75
+
-[ ] Create release branch for docker-images
76
+
-[ ] Create release branches for operators
77
+
-[ ] Create release branch for demos
78
+
-[ ]_Wait for images to be built before proceeding_
71
79
72
-
### End of the release cycle (Release day)
80
+
## Release candidate testing
81
+
82
+
> [!WARNING]
83
+
> To be discussed during the on-site.
84
+
>
85
+
> Getting started scripts use particular product versions (this would have been updated in the
86
+
> early-pre-release stage), however, at this point in time, the images will be tagged with an rcX
87
+
> tag.
88
+
89
+
<!--
90
+
91
+
> [!TIP]
92
+
> As issues are discovered, they can be fixed on the `main` branch, and cherry-picked into the release branch.
93
+
>
94
+
> Please ensure the changelog is updated and correct for the release after cherry-picking changes.
95
+
> Please also keep PR links as they are in `main` (do not update them for the cherry-picked PR).
73
96
74
-
```[tasklist]
75
-
#### Technical tasks
76
-
- [ ] Create release branch for docker-images (see stackable-utils for script to create branches)
77
-
- [ ] Create release branches for operators (see stackable-utils for script to create branches)
78
-
- [ ] Create release branch for demos (see stackable-utils for script to create branches)
79
-
- [ ] _Wait for images to be built_
80
97
- [ ] [Check and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=07-release-getting-started-scripts.md) for the Release Candidate
81
98
- [ ] [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)
82
-
- [ ] Create release tag(s) for docker-images (see stackable-utils for scripts to create tags)
83
-
- [ ] Create release tag(s) for operators (see stackable-utils for scripts to create tags)
84
-
- [ ] Update release version in changelogs on main branches (see stackable-utils for script to do this)
85
-
- [ ] Generate CRD docs [website](https://crds.stackable.tech/) for the new release by following these [instructions](https://github.com/stackabletech/crddocs)
99
+
100
+
-->
101
+
102
+
## Release tagging
103
+
104
+
> [!TIP]
105
+
> See [stackable-utils] for script to create tags and update changelogs.
106
+
107
+
-[ ] Create release tag(s) for docker-images
108
+
-[ ] Create release tag(s) for operators
109
+
-[ ] Update release version in changelogs on main branches
110
+
-[ ]_Wait for images to be built before proceeding_
86
111
-[ ] Test `stackablectl` with locally updated (to new release number) `releases.yaml`
87
-
- [ ] Update `release.yaml` in https://github.com/stackabletech/release/blob/main/releases.yaml
88
-
- [ ] [Check and update getting-started scripts](https://github.com/stackabletech/issues/issues/new?template=07-release-getting-started-scripts.md)
89
-
- [ ] [Test demos and upgrade from previous to this release](https://github.com/stackabletech/demos/issues/new?template=release-upgrade-testing.md)
> 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].
-[ ] Generate CRD docs [website][dt-1] for the new release by following these [instructions][dt-2]
103
135
-[ ] Create a stackabletech/documentation branch called `docs/release-notes-YY.M.X`
104
136
-[ ] Compile list of new product features in newly supported versions for the YY.M.X release (for the blog post)
105
-
- [ ] 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)
137
+
-[ ] Begin writing the release notes with the [Pull Request template][dt-3]
106
138
-[ ] Update SDP release version in `documentation/modules/ROOT/pages/getting-started.adoc` and test the release install command
107
-
- [ ] Cut a release branch (see [scripts/make-release-branch.sh](https://github.com/stackabletech/documentation/blob/main/scripts/make-release-branch.sh))
108
-
- [ ] Update releases in the playbook (see [scripts/publish-new-version.sh](https://github.com/stackabletech/documentation/blob/main/scripts/publish-new-version.sh))
139
+
-[ ] Cut a release branch (see [scripts/make-release-branch.sh][dt-4])
140
+
-[ ] Update releases in the playbook (see [scripts/publish-new-version.sh][dt-5])
109
141
-[ ] Remove any references to HEAD and main from the Antora playbooks on the release branch (replace with the release branch)
110
142
-[ ] 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.
111
143
-[ ] Set the release to "Released" in the Feature Tracker and create a new release (ping @lfrancke)
112
-
- [ ] 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
113
-
```
144
+
-[ ] Update the [getting-started page][dt-6] in the main docs and check it works with this release
Marketing tasks can now reference published documentation.
154
+
## Marketing tasks
155
+
156
+
> [!NOTE]
157
+
> Marketing material can now reference published documentation.
116
158
117
-
```[tasklist]
118
-
#### Marketing tasks
119
159
-[ ] Write marketing / customer oriented release summary to be published in the marketing channels
120
160
-[ ] Update the homepage banner (as long as we have it) to point to the new release
121
161
-[ ] Write a blogpost / news article announcing the new release (optional)
@@ -127,19 +167,22 @@ Marketing tasks can now reference published documentation.
127
167
-[ ] 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
128
168
-[ ] Post an announcement in Discord
129
169
-[ ] Post an announcement on DOK Community in the #be-shameless Channel (Ping Lars or Jim)
-[ ] Post an announcement via OSBA (Ping Lars, <mailto:[email protected]>)
131
171
-[ ] Send announcement to Kubernetes Podcast (Ping Lars)
132
172
-[ ] Send announcement to Heiser
133
173
-[ ] Ping the stackable-ionos-tech channel or anyone responsible once all tags are created
134
-
```
135
174
136
-
```[tasklist]
137
-
#### Post-release tasks
175
+
## Post-release tasks
176
+
138
177
-[ ] Test demo upgrades, which were skipped in the previous testing (optional)
139
-
- [ ] Update the list of supported SDP releases in Jira (ping Jim)
140
-
- [ ] 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
141
-
- [ ] 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).
142
-
- [ ] Post YY.M.X release retro (use issue created at the start of the process)
143
-
- [ ] Update the release tracking template (optional)
144
-
- [ ] [Create the next release tracking task](https://github.com/stackabletech/issues/issues/new?template=06-release.md) (if the date is available)
145
-
```
178
+
-[ ] Update the list of supported SDP releases in Jira (ping @Jimvin)
179
+
-[ ] Openshift certification. [Create an issue][pt-1] to track the creation of the OLM manifests
180
+
-[ ] Mark any releases older than one year as "end-of-life" in the documentation (update [antora.yaml][pt-2] on the applicable branches).
181
+
-[ ]_Link to release retro issue (use issue created at the start of the process)_
182
+
-[ ] Update the release tracking templates (optional)
183
+
-[ ][Create the next release tracking task][pt-3] (if the date is available)
0 commit comments