waku-org
/
nwaku
mirror of https://github.com/waku-org/nwaku.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
nwaku/.github/ISSUE_TEMPLATE/prepare_release.md

4.1 KiB
Raw Blame History

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

  • 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

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

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