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

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

Note that status.staging refers to shards.staging fleet (rename is wip).

  • 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. 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
      • Ask other (Waku and Status) CCs to point their instance to status.staging for a week and use the app as usual.
      • 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.