Prepare release 0.33.0

[gabrielmer]

Items to complete

All items below are to be completed by the owner of the given release.

• [x] Create release branch

• [x] Assign release candidate tag to the release branch HEAD. e.g. v0.30.0-rc.0

• [x] Generate and edit releases notes in CHANGELOG.md

• [x] Review possible update of config-options

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

• [x] Validate release candidate

• [ ] Automated testing

  • [ ] Ensures js-waku tests are green against release candidate

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

  • [x] On Waku fleets

  • [x] Lock waku.test fleet to release candidate version

  • [x] Continuously stress waku.test fleet for a week (e.g. from wakudev)

  • [x] 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"

  • [x] Run release candidate with waku-simulator, ensure that nodes connected to each other

  • [x] Unlock waku.test to resume auto-deployment of latest master commit

  • [x] On Status fleet

  • [x] Deploy release candidate to status.staging

  • [x] Perform sanity check and log results as comments in this issue.

    • [x] Connect 2 instances to status.staging fleet, one in relay mode, the other one in light client.
    • [x] 1:1 Chats with each other
    • [x] Send and receive messages in a community
    • [x] Close one instance, send messages with second instance, reopen first instance and confirm messages sent while offline are retrieved from store

  • [x] Perform checks based end user impact

  • [x] 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.)

  • [x] Ask Status-QA to perform sanity checks (as described above) + checks based on end user impact; do specify the version being tested

  • [x] Ask Status-QA or infra to run the automated Status e2e tests against status.staging

  • [x] Get other CCs sign-off: they comment on this PR "used app for a week, no problem", or problem reported, resolved and new RC

  • [x] Get Status-QA sign-off. Ensuring that status.test update will not disturb ongoing activities.

• [x] Proceed with release

  • [x] Assign a release tag to the same commit that contains the validated release-candidate tag
  • [x] Create GitHub release
  • [x] Deploy the release to DockerHub
  • [x] Announce the release

• [x] Promote release to fleets.

  • [x] Update infra config with any deprecated arguments or changed options
  • [x] Deploy final release to waku.sandbox fleet
  • [x] Deploy final release to status.staging fleet
  • [x] Deploy final release to status.prod fleet

• [x] Post release

  • [x] Submit a PR from the release branch to master. Important to commit the PR with "create a merge commit" option.
  • [x] Update waku-org/nwaku-compose with the new release version.

[gabrielmer]

This release shouldn't have any impact on Status performance. The major features (experimental reliability protocol and peer exchange rate limiting) are still off by default until further testing is done.

Apart from that, we improved vastly our capabilities of monitoring store performance and completed some major refactors. However, none of this affects performance.

[gabrielmer]

Peer discovery, message delivery, store queries, and Status Communities look healthy