mirror of
https://github.com/logos-messaging/logos-messaging-nim.git
synced 2026-01-03 22:43:09 +00:00
* fix: fix .github waku-org/ --> logos-messaging/ * bump CI tests timeout 45 --> 90 minutes * fix .gitmodules waku-org --> logos-messaging
5.3 KiB
5.3 KiB
| name | about | title | labels | assignees |
|---|---|---|---|---|
| Prepare Full Release | Execute tasks for the creation and publishing of a new full release | Prepare full release 0.0.0 | full-release |
Items to complete
All items below are to be completed by the owner of the given release.
-
Create release branch with major and minor only ( e.g. release/v0.X ) if it doesn't exist.
-
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). -
Generate and edit release notes in CHANGELOG.md.
-
Validation of release candidate
-
Automated testing
- Ensure all the unit tests (specifically js-waku tests) are green against the release candidate.
- Ask Vac-QA and Vac-DST to perform the available tests against the release candidate.
- Vac-DST (an additional report is needed; see this)
-
Waku fleet testing
- Deploy the release candidate to
waku.testandwaku.sandboxfleets.- Start the deployment job for both fleets and wait for it to finish (Jenkins access required; ask the infra team if you don't have it).
- After completion, disable deployment job so that its version is not updated on every merge to
master. - Verify the deployed version at https://fleets.waku.org/.
- Confirm the container image exists on Harbor.
- Search Kibana logs from the previous month (since the last release was deployed) for possible crashes or errors in
waku.testandwaku.sandbox.- Most relevant logs are
(fleet: "waku.test" AND message: "SIGSEGV")OR(fleet: "waku.sandbox" AND message: "SIGSEGV").
- Most relevant logs are
- Enable again the
waku.testfleet to resume auto-deployment of the latestmastercommit.
- Deploy the release candidate to
-
-
Status fleet testing
- Deploy release candidate to
status.staging - Perform sanity check and log results as comments in this issue.
- Connect 2 instances to
status.stagingfleet, one in relay mode, the other one in light client.- 1:1 Chats with each other
- Send and receive messages in a community
- Close one instance, send messages with second instance, reopen first instance and confirm messages sent while offline are retrieved from store
- Perform checks based on end user impact
- Inform other (Waku and Status) CCs to point their instances to
status.stagingfor a few days. Ping Status colleagues on their Discord server or in the Status community (this is not a blocking point.) - Ask Status-QA to perform sanity checks (as described above) and checks based on end user impact; specify the version being tested
- Ask Status-QA or infra to run the automated Status e2e tests against
status.staging - 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.
- Get Status-QA sign-off, ensuring that the
status.testupdate will not disturb ongoing activities.
- Connect 2 instances to
- Deploy release candidate to
-
Proceed with release
- Assign a final release tag (
v0.X.0) to the same commit that contains the validated release-candidate tag (e.g.v0.X.0). - Update nwaku-compose and waku-simulator according to the new release.
- Bump nwaku dependency in waku-rust-bindings and make sure all examples and tests work.
- Bump nwaku dependency in waku-go-bindings and make sure all tests work.
- Create GitHub release (https://github.com/logos-messaging/nwaku/releases).
- 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.
- Assign a final release tag (
-
Promote release to fleets
- Ask the PM lead to announce the release.
- Update infra config with any deprecated arguments or changed options.