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: docs/release/README.md
+35-6Lines changed: 35 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,19 +6,38 @@ This document contains the instructions for the DevWorkspace Operator release pr
6
6
7
7
The release process is powered by the 'Release DevWorkspace Operator' [GitHub Action](https://github.com/devfile/devworkspace-operator/actions/workflows/release.yml).
8
8
9
-
In order to release a new version of the DevWorkspace Operator:
10
-
11
-
1. Trigger the prerelease by running the action using the workflow from the `main` branch. Provide the version in format `v0.y.z` e.g. `v0.13.0` and set `true` for the prelease field:
9
+
### Preparing release branch
10
+
Trigger the prerelease by running the 'Release DevWorkspace Operator' action using the workflow from the `main` branch. Provide the version in format `v0.y.z` e.g. `v0.13.0` and set `true` for the prelease field:
The action will create the dedicated release branch e.g. `0.13.x` and the prelease commit e.g https://github.com/devfile/devworkspace-operator/commit/4905c6c695e4d4945a3810df9a46a5ecf11d09f1
16
15
17
-
> :warning: If necessary, cherry-pick any additional fixes to the release branch.
16
+
This step is required for every new minor release of the DevWorkspace Operator.
17
+
18
+
### Testing prerelease artifacts
19
+
20
+
The release job updates the yaml files used to deploy the DevWorkspace Operator to use the new images. However, for commits that aren't tagged for release, these yaml files will refer to still-unbuilt container images. For example, commits in the `0.15.x` branch will use `quay.io/devfile/devworkspace-controller:v0.15.0`, but that image will only be pushed once the full release happens.
21
+
22
+
This means that to test commits in a release branch before running the release job, it's necessary to manually build all DevWorkspace Operator images and override them in the deployment:
Build the image from the `0.13.x` branch and run manually a test with DevWorkspace startup against this version of the operator. If the workspace is started without errors you can proceed with the release.
36
+
### Releasing a new version
20
37
21
-
2. Trigger the release by running the same action using the workflow from the branch that was created during the previous step e.g. `0.13.x`. Provide the version in format `v0.y.z` e.g. `v0.13.0` and set `false` for the prelease field:
38
+
> :warning: If necessary, cherry-pick any additional fixes to the release branch.
39
+
40
+
Trigger the release by running the 'Release DevWorkspace Operator' action using the workflow from the release branch that was created in the pre-release setup, e.g. `0.13.x`. Provide the version in format `v0.y.z`, e.g. `v0.13.0` and set `false` for the prelease field:
22
41
23
42

24
43
@@ -31,3 +50,13 @@ The action will create the release commit with the new OLM bundle e.g. https://g
31
50
The index image with the `release` tag is also pushed automatically to quay.io:
After releasing a new version of the DevWorkspace Operator, it is necessary to copy the bundle files generated for that release to the main branch by opening a PR.
55
+
56
+
### Creating a bugfix release
57
+
58
+
To create a bugfix release, the process is the same as [releasing](#releasing-a-new-version) above:
59
+
60
+
1. Cherry-pick any commits required for the bugfix release
61
+
2. Trigger the 'Release DevWorkspace Operator' action using the release branch (e.g. `0.13.x`), with `prerelease: false`
62
+
3. Open a PR to add the bundle files created for the new release to the main branch.
0 commit comments