mirror of https://github.com/waku-org/nwaku.git
3.7 KiB
3.7 KiB
name | about | title | labels | assignees |
---|---|---|---|---|
Prepare release | Execute tasks for the creation and publishing of a new release | Prepare release 0.0.0 | release |
Items to complete
All items below are to be completed by the owner of the given release.
-
Create release branch
-
Assign release candidate tag to the release branch HEAD. e.g. v0.30.0-rc.0
-
Generate and edit releases notes in CHANGELOG.md
-
End user impact: Summarize impact of changes on Status end users (can be a comment in this issue).
-
Validate release candidate
-
Automated testing
-
Ensures js-waku tests are green against release candidate
-
Ask Vac-QA and Vac-DST to perform available tests against release candidate
-
On Waku fleets
- Lock
waku.test
fleet to release candidate version - Continuously stress
waku.test
fleet for a week (e.g. fromwakudev
) - Search Kibana logs from the previous month (since last release was deployed), for possible crashes or errors in
waku.test
andwaku.sandbox
.- Most relevant logs are
(fleet: "waku.test" OR fleet: "waku.sandbox") AND message: "SIGSEGV"
- Most relevant logs are
- Run release candidate with
waku-simulator
, ensure that nodes connected to each other - Unlock
waku.test
to resume auto-deployment of latestmaster
commit
- Lock
-
On Status fleet
- Deploy release candidate to
status.staging
- Perform sanity check and log results as comments in this issue.
- Connect 2 instances to
status.staging
fleet, 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
- Connect 2 instances to
- Perform checks based end user impact
- 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 (not blocking point.) - Ask Status-QA to perform sanity checks (as described above) + checks based on end user impact; do 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 comment on this PR "used app for a week, no problem", or problem reported, resolved and new RC
- Get Status-QA sign-off. Ensuring that
status.test
update will not disturb ongoing activities.
- Deploy release candidate to
-
-
Proceed with release
- Assign a release tag to the same commit that contains the validated release-candidate tag
- Create GitHub release
- Deploy the release to DockerHub
- Announce the release
-
Promote release to fleets.
- Update infra config with any deprecated arguments or changed options
- Deploy final release to
waku.sandbox
fleet - Deploy final release to
status.staging
fleet - Deploy final release to
status.prod
fleet
-
Post release
- Submit a PR from the release branch to master. Important to commit the PR with "create a merge commit" option.
- Update waku-org/nwaku-compose with the new release version.