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/prepare_beta_release.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
name: Prepare Beta Release
3
-
about: Execute tasks for the creation and publishing of a new beta release.
3
+
about: Execute tasks for the creation and publishing of a new beta release
4
4
title: 'Prepare beta release 0.0.0'
5
5
labels: beta-release
6
6
assignees: ''
@@ -17,13 +17,13 @@ For detailed info on the release process refer to https://github.com/waku-org/nw
17
17
18
18
All items below are to be completed by the owner of the given release.
19
19
20
-
-[ ] Create release branch (e.g. release/v0.X.0-beta) if it doesn't exist.
21
-
-[ ] Assign release candidate tag to the release branch HEAD. e.g. v0.X.0-beta-rc.0, v0.X.0-beta-rc.1, ... v0.X.0-beta-rc.N etc.
20
+
-[ ] Create release branch (e.g. `release/v0.X.0-beta`) if it doesn't exist.
21
+
-[ ] Assign release candidate tag to the release branch HEAD (e.g. `v0.X.0-beta-rc.0`, `v0.X.0-beta-rc.1`, ... `v0.X.0-beta-rc.N`).
22
22
-[ ] Generate and edit release notes in CHANGELOG.md.
23
23
24
24
-[ ]**Waku test and fleets validation**
25
25
-[ ] Ensure all the unit tests (specifically js-waku tests) are green against the release candidate.
26
-
-[ ] Deploy the release candidate to `waku.test` only through [deploy-waku-test job](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-test/) and wait for it to finish (Jenkins access required; ask the infra team if you don't have it.).
26
+
-[ ] Deploy the release candidate to `waku.test` only through [deploy-waku-test job](https://ci.infra.status.im/job/nim-waku/job/deploy-waku-test/) and wait for it to finish (Jenkins access required; ask the infra team if you don't have it).
27
27
- After completion, disable [deployment job](https://ci.infra.status.im/job/nim-waku/) so that its version is not updated on every merge to master.
28
28
- Verify the deployed version at https://fleets.waku.org/.
29
29
- Confirm the container image exists on [Harbor](https://harbor.status.im/harbor/projects/9/repositories/nwaku/artifacts-tab).
@@ -33,14 +33,14 @@ All items below are to be completed by the owner of the given release.
33
33
34
34
-[ ]**Proceed with release**
35
35
36
-
-[ ] Assign a final release tag (v0.X.0-beta) to the same commit that contains the validated release-candidate tag (e.g. v0.X.0-beta-rc.N) and submit a PR from the release branch to master.
36
+
-[ ] Assign a final release tag (`v0.X.0-beta`) to the same commit that contains the validated release-candidate tag (e.g. `v0.X.0-beta-rc.N`) and submit a PR from the release branch to `master`.
37
37
-[ ] Update [nwaku-compose](https://github.com/waku-org/nwaku-compose) and [waku-simulator](https://github.com/waku-org/waku-simulator) according to the new release.
38
38
-[ ] Bump nwaku dependency in [waku-rust-bindings](https://github.com/waku-org/waku-rust-bindings) and make sure all examples and tests work.
39
39
-[ ] Bump nwaku dependency in [waku-go-bindings](https://github.com/waku-org/waku-go-bindings) and make sure all tests work.
-[ ] Submit a PR to merge the release branch back to `master`. Make sure you use the option `Merge pull request (Create a merge commit)` to perform such merge. Ping repo admin if this option is not available.
41
+
-[ ] Submit a PR to merge the release branch back to `master`. Make sure you use the option "Merge pull request (Create a merge commit)" to perform the merge. Ping repo admin if this option is not available.
42
42
43
-
-[ ]**Promote release to fleets**.
43
+
-[ ]**Promote release to fleets**
44
44
-[ ] Ask the PM lead to announce the release.
45
45
-[ ] Update infra config with any deprecated arguments or changed options.
Copy file name to clipboardExpand all lines: .github/ISSUE_TEMPLATE/prepare_full_release.md
+12-12Lines changed: 12 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,26 +17,26 @@ For detailed info on the release process refer to https://github.com/waku-org/nw
17
17
18
18
All items below are to be completed by the owner of the given release.
19
19
20
-
-[ ] Create release branch (e.g. release/v0.X.0-beta ) if it doesn't exist.
21
-
-[ ] Assign release candidate tag to the release branch HEAD. e.g. v0.X.0-beta-rc.0, v0.X.0-beta-rc.1, ... v0.X.0-beta-rc.N etc.
22
-
-[ ] Generate and edit release notes in CHANGELOG.md
20
+
-[ ] Create release branch (e.g. `release/v0.X.0`) if it doesn't exist.
21
+
-[ ] Assign release candidate tag to the release branch HEAD (e.g. `v0.X.0-rc.0`, `v0.X.0-rc.1`, ... `v0.X.0-rc.N`).
22
+
-[ ] Generate and edit release notes in CHANGELOG.md.
23
23
24
24
-[ ]**Validation of release candidate**
25
25
26
26
-[ ]**Automated testing**
27
27
-[ ] Ensure all the unit tests (specifically js-waku tests) are green against the release candidate.
28
-
-[ ] Ask Vac-QA and Vac-DST to perform the available tests against the release candidate
28
+
-[ ] Ask Vac-QA and Vac-DST to perform the available tests against the release candidate.
29
29
-[ ] Vac-DST (an additional report is needed; see [this](https://www.notion.so/DST-Reports-1228f96fb65c80729cd1d98a7496fe6f))
30
30
31
31
-[ ]**Waku fleet testing**
32
32
-[ ] Deploy the release candidate to `waku.test` and `waku.sandbox` fleets.
33
33
- Start the [deployment job](https://ci.infra.status.im/job/nim-waku/) for both fleets and wait for it to finish (Jenkins access required; ask the infra team if you don't have it).
34
-
- After completion, disable [deployment job](https://ci.infra.status.im/job/nim-waku/) so that its version is not updated on every merge to master
34
+
- After completion, disable [deployment job](https://ci.infra.status.im/job/nim-waku/) so that its version is not updated on every merge to `master`.
35
35
- Verify the deployed version at https://fleets.waku.org/.
36
36
- Confirm the container image exists on [Harbor](https://harbor.status.im/harbor/projects/9/repositories/nwaku/artifacts-tab).
37
37
-[ ] Search _Kibana_ logs from the previous month (since the last release was deployed) for possible crashes or errors in `waku.test` and `waku.sandbox`.
38
38
- Most relevant logs are `(fleet: "waku.test" AND message: "SIGSEGV")` OR `(fleet: "waku.sandbox" AND message: "SIGSEGV")`.
39
-
-[ ] Enable again the `waku.test` fleet to resume auto-deployment of the latest `master` commit
39
+
-[ ] Enable again the `waku.test` fleet to resume auto-deployment of the latest `master` commit.
40
40
41
41
-[ ]**Status fleet testing**
42
42
-[ ] Deploy release candidate to `status.staging`
@@ -54,15 +54,15 @@ All items below are to be completed by the owner of the given release.
54
54
55
55
-[ ]**Proceed with release**
56
56
57
-
-[ ] Assign a final release tag (v0.X.0) to the same commit that contains the validated release-candidate tag (e.g. v0.X.0-beta)
57
+
-[ ] Assign a final release tag (`v0.X.0`) to the same commit that contains the validated release-candidate tag (e.g. `v0.X.0-rc.N`).
58
58
-[ ] Update [nwaku-compose](https://github.com/waku-org/nwaku-compose) and [waku-simulator](https://github.com/waku-org/waku-simulator) according to the new release.
59
59
-[ ] Bump nwaku dependency in [waku-rust-bindings](https://github.com/waku-org/waku-rust-bindings) and make sure all examples and tests work.
60
60
-[ ] Bump nwaku dependency in [waku-go-bindings](https://github.com/waku-org/waku-go-bindings) and make sure all tests work.
-[ ] Submit a PR to merge the release branch back to `master`. Make sure you use the option `Merge pull request (Create a merge commit)` to perform such merge. Ping repo admin if this option is not available.
-[ ] Submit a PR to merge the release branch back to `master`. Make sure you use the option "Merge pull request (Create a merge commit)" to perform the merge. Ping repo admin if this option is not available.
63
63
64
-
-[ ]**Promote release to fleets**.
65
-
-[ ] Ask for release announcement to PM lead.
64
+
-[ ]**Promote release to fleets**
65
+
-[ ] Ask the PM lead to announce the release.
66
66
-[ ] Update infra config with any deprecated arguments or changed options.
67
67
68
68
### Links
@@ -72,5 +72,5 @@ All items below are to be completed by the owner of the given release.
@@ -70,39 +70,39 @@ For more context, see https://trunkbaseddevelopment.com/branch-for-release/
70
70
71
71
6a. **Automated testing**
72
72
- Ensure all the unit tests (specifically js-waku tests) are green against the release candidate.
73
-
- Ask Vac-QA and Vac-DST to run their available tests against the release candidate, share all release candidate with both team.
73
+
- Ask Vac-QA and Vac-DST to run their available tests against the release candidate; share all release candidates with both teams.
74
74
75
-
> We need additional report like [this](https://www.notion.so/DST-Reports-1228f96fb65c80729cd1d98a7496fe6f) specificly from DST team.
75
+
> We need an additional report like [this](https://www.notion.so/DST-Reports-1228f96fb65c80729cd1d98a7496fe6f) specifically from the DST team.
76
76
77
77
6b. **Waku fleet testing**
78
-
- Start job on `waku.sandbox` and `waku.test` [Deployment job](https://ci.infra.status.im/job/nim-waku/), Wait for completion of the job. If it fails, then debug it.
79
-
- After completion, disable [deployment job](https://ci.infra.status.im/job/nim-waku/) so that its version is not updated on every merge to master.
78
+
- Start job on `waku.sandbox` and `waku.test` [Deployment job](https://ci.infra.status.im/job/nim-waku/), wait for completion of the job. If it fails, then debug it.
79
+
- After completion, disable [deployment job](https://ci.infra.status.im/job/nim-waku/) so that its version is not updated on every merge to `master`.
80
80
- Verify at https://fleets.waku.org/ that the fleet is locked to the release candidate version.
81
-
- Check if the image is created at [harbor](https://harbor.status.im/harbor/projects/9/repositories/nwaku/artifacts-tab).
81
+
- Check if the image is created at [Harbor](https://harbor.status.im/harbor/projects/9/repositories/nwaku/artifacts-tab).
82
82
- Search _Kibana_ logs from the previous month (since the last release was deployed) for possible crashes or errors in `waku.test` and `waku.sandbox`.
83
83
- Most relevant logs are `(fleet: "waku.test" AND message: "SIGSEGV")` OR `(fleet: "waku.sandbox" AND message: "SIGSEGV")`.
84
-
- Enable again the `waku.test` fleet to resume auto-deployment of the latest `master` commit
84
+
- Enable the `waku.test` fleet again to resume auto-deployment of the latest `master` commit.
85
85
86
86
6c. **Status fleet testing**
87
87
- Deploy release candidate to `status.staging`
88
88
- Perform [sanity check](https://www.notion.so/How-to-test-Nwaku-on-Status-12c6e4b9bf06420ca868bd199129b425) and log results as comments in this issue.
89
89
- Connect 2 instances to `status.staging` fleet, one in relay mode, the other one in light client.
90
-
- 1:1 chats with each other
90
+
- 1:1 Chats with each other
91
91
- Send and receive messages in a community
92
92
- Close one instance, send messages with second instance, reopen first instance and confirm messages sent while offline are retrieved from store
93
-
- Perform checks based on _end-user impact_
94
-
- Inform other (Waku and Status) CCs to point their instance to `status.staging` for a few days. Ping Status colleagues from their Discord server or [Status community](https://status.app) (not blocking point.)
95
-
- Ask Status-QA to perform sanity checks (as described above) + checks based on _end user impact_; do specify the version being tested
96
-
- Ask Status-QA or infra to run the automated Status e2e tests against `status.staging`
97
-
- Get other CCs sign-off: they comment on this PR "used app for a week, no problem", or problem reported, resolved and new RC
98
-
- **Get Status-QA sign-off**. Ensuring that `status.test` update will not disturb ongoing activities.
93
+
- Perform checks based on _end-user impact_.
94
+
- Inform other (Waku and Status) CCs to point their instances to `status.staging` for a few days. Ping Status colleagues from their Discord server or [Status community](https://status.app) (not a blocking point).
95
+
- Ask Status-QA to perform sanity checks (as described above) and checks based on _end user impact_; specify the version being tested.
96
+
- Ask Status-QA or infra to run the automated Status e2e tests against `status.staging`.
97
+
- Get other CCs' sign-off: they should comment on this PR, e.g., "Used the app for a week, no problem." If problems are reported, resolve them and create a new RC.
98
+
- **Get Status-QA sign-off**, ensuring that the `status.test` update will not disturb ongoing activities.
99
99
100
100
7. Once the release-candidate has been validated, create a final release tag and push it.
101
101
We also need to merge the release branch back into master as a final step.
102
102
103
103
```
104
104
git checkout release/v0.X.0
105
-
git tag -as v0.X.0 -m "final release." (use v0.X.0-beta as the tag if you are creating a beta release)
105
+
git tag -as v0.X.0 -m "final release." (use v0.X.0-beta as the tag if you are creating a beta release)
106
106
git push origin v0.X.0
107
107
git switch master
108
108
git pull
@@ -153,5 +153,5 @@ We also need to merge the release branch back into master as a final step.
0 commit comments