Prepare release 0.32.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] End user impact: Summarize impact of changes on Status end users (can be a comment in this issue).

• [x] Validate release candidate

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

For Status the impact of this release would be:

• Improved store query times by https://github.com/waku-org/nwaku/commit/32f2d85d and https://github.com/waku-org/nwaku/commit/4d47aa65
• Improved Waku Peer Exchange responses only with peers in the relevant cluster

[gabrielmer]

Peer discovery, message delivery and store queries look healthy