logos-messaging/logos-delivery
1
0
Fork 0
mirror of https://github.com/logos-messaging/logos-delivery.git synced 2026-03-15 13:33:10 +00:00
Code Issues Packages Projects Releases Wiki Activity
logos-delivery/.github/ISSUE_TEMPLATE/prepare_release.md
Ivan FB a77870782a
Change release process (#3750) 
* Simplify release process and leave the DST validation for deployment process
* Rename prepare_full_release.md to prepare_release.md
* Remove release-process.md as it duplicates info and causes confusion
2026-03-12 19:13:09 +01:00

5.6 KiB
Raw Blame History

name about title labels assignees
Prepare Release Execute tasks for the creation and publishing of a new full release Prepare 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.

    • QA testing

      • Ask QA to run their available tests 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.
      • Ask QA to perform tests against waku.test, if any. Then, after that, review Kibana for possible issues or unexpected restart.
      • Enable the waku.test fleet again to resume auto-deployment of the latest master commit.

    • Status testing

      • Get QA approval to deploy a new version in status.staging.
      • 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 mode.
          • 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 QA to perform sanity checks (as described above) and checks based on end user impact; specify the version being tested
        • Ask 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.

  • Proceed with release

Links