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

• Review possible update of config-options

• End user impact: Summarize impact of changes on Status end users (can be a comment in this issue).

• Validate release candidate

  • Bump nwaku dependency in waku-rust-bindings and make sure all examples and tests work

• Automated testing

  • Ensures js-waku tests are green against release candidate

  • Ask Vac-QA and Vac-DST to perform available tests against release candidate

    • Vac-QA
    • Vac-DST (we need additional report. see this)

  • On Waku fleets

    • Lock waku.test fleet to release candidate version
    • Continuously stress waku.test fleet for a week (e.g. from wakudev)
    • Search Kibana logs from the previous month (since last release was deployed), for possible crashes or errors in waku.test and waku.sandbox.
      • Most relevant logs are (fleet: "waku.test" OR fleet: "waku.sandbox") AND message: "SIGSEGV"
    • Run release candidate with waku-simulator, ensure that nodes connected to each other
    • Unlock waku.test to resume auto-deployment of latest master commit

  • 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
    • 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.

• 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.
  • Update version in js-waku repo. update only this by submitting a PR.