logos-messaging-nim/.github/ISSUE_TEMPLATE/prepare_full_release.md
2026-02-18 11:51:15 +05:30

6.4 KiB

name about title labels assignees
Prepare Full Release Execute tasks for the creation and publishing of a new full release Prepare full release 0.0.0 full-release

Items to complete

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

  • Create release branch with major and minor only ( e.g. release/v0.X ) if it doesn't exist.

  • Assign release candidate tag to the release branch HEAD (e.g. v0.X.0-rc.0, v0.X.0-rc.1, ... v0.X.0-rc.N).

  • Generate and edit release notes in CHANGELOG.md.

  • Validation of release candidate

    • Automated testing

      • Ensure all the unit tests (specifically logos-messaging-js tests) are green against the release candidate.
    • Waku fleet testing

      • Deploy the release candidate to waku.test fleet.
        • Start the deployment job and wait for it to finish (Jenkins access required; ask the infra team if you don't have it).
        • After completion, disable fleet so that daily CI does not override your release candidate.
        • Verify at https://fleets.waku.org/ that the fleet is locked to the release candidate image.
        • Confirm the container image exists on Harbor.
      • Search Kibana logs from the previous month (since the last release was deployed) for possible crashes or errors in waku.test.
        • Set time range to "Last 30 days" (or since last release).
        • Most relevant search query: (fleet: "waku.test" AND message: "SIGSEGV"), (fleet: "waku.test" AND message: "exception"), (fleet: "waku.test" AND message: "error").
        • Document any crashes or errors found.
      • If waku.test validation is successful, deploy to waku.sandbox using the same deployment job.
      • Search Kibana logs for waku.sandbox: (fleet: "waku.sandbox" AND message: "SIGSEGV"), (fleet: "waku.sandbox" AND message: "exception"), (fleet: "waku.sandbox" AND message: "error"). most probably if there are no crashes or errors in waku.test, there will be no crashes or errors in waku.sandbox.
      • Enable the waku.test fleet again to resume auto-deployment of the latest master commit.
    • QA and DST testing

      • Ask Vac-QA and Vac-DST to run their available tests against the release candidate; share all release candidates with both teams.
      • Vac-DST: An additional report is needed (see this example). Inform DST team about what are the expectations for this rc. For example, if we expect higher or lower bandwidth consumption.
    • Status fleet testing

      • 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 on end user impact
        • Inform other (Waku and Status) CCs to point their instances to status.staging for a few days. Ping Status colleagues on their Discord server or in the Status community (this is not a blocking point.)
        • Ask Status-QA to perform sanity checks (as described above) and checks based on end user impact; 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 should comment on this PR, e.g., "Used the app for a week, no problem." If problems are reported, resolve them and create a new RC.
        • Get Status-QA sign-off, ensuring that the status.test update will not disturb ongoing activities.
  • Proceed with release

  • Promote release to fleets

    • Ask the PM lead to announce the release.
    • Update infra config with any deprecated arguments or changed options.