Release Process

How to do releases.

For more context, see https://trunkbaseddevelopment.com/branch-for-release/

How to do releases

Prerequisites

All issues under the corresponding release milestone have been closed or, after consultation, deferred to the next release.
All submodules are up to date.

Updating submodules requires a PR (and very often several "fixes" to maintain compatibility with the changes in submodules). That PR process must be done and merged a couple of days before the release.

In case the submodules update has a low effort and/or risk for the release, follow the "Update submodules" instructions.

If the effort or risk is too high, consider postponing the submodules upgrade for the subsequent release or delaying the current release until the submodules updates are included in the release candidate.

Release types

Full release: follow the entire Release process.
Beta release: skip just 6a and 6c steps from Release process.
Choose the appropriate release process based on the release type:
- Full Release
- Beta Release

Release process ( step by step )

Checkout a release branch from master
```
git checkout -b release/v0.X.0
```
Update CHANGELOG.md and ensure it is up to date. Use the helper Make target to get PR based release-notes/changelog update.
```
make release-notes
```
Create a release-candidate tag with the same name as release and -rc.N suffix a few days before the official release and push it
```
git tag -as v0.X.0-rc.0 -m "Initial release."
git push origin v0.X.0-rc.0
```
This will trigger a workflow which will build RC artifacts and create and publish a GitHub release
Open a PR from the release branch for others to review the included changes and the release-notes

In case additional changes are needed, create a new RC tag

Make sure the new tag is associated with CHANGELOG update.

# Make changes, rebase and create new tag
# Squash to one commit and make a nice commit message
git rebase -i origin/master
git tag -as v0.X.0-rc.1 -m "Initial release."
git push origin v0.X.0-rc.1

Similarly use v0.X.0-rc.2, v0.X.0-rc.3 etc. for additional RC tags.

Validation of release candidate

6a. Automated testing
- Ensure all the unit tests (specifically js-waku tests) are green against the release candidate.
- Ask Vac-QA and Vac-DST to run their available tests against the release candidate; share all release candidates with both teams.
We need an additional report like this specifically from the DST team.

6b. Waku fleet testing
- Start job on waku.sandbox and waku.test Deployment job, wait for completion of the job. If it fails, then debug it.
- After completion, disable deployment job so that its version is not updated on every merge to master.
- Verify at https://fleets.waku.org/ that the fleet is locked to the release candidate version.
- Check if the image is created at Harbor.
- Search Kibana logs from the previous month (since the last release was deployed) for possible crashes or errors in waku.test and waku.sandbox.
  - Most relevant logs are (fleet: "waku.test" AND message: "SIGSEGV") OR (fleet: "waku.sandbox" AND message: "SIGSEGV").
- Enable the waku.test fleet again to resume auto-deployment of the latest master commit.
6c. 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 from their Discord server or Status community (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.

Once the release-candidate has been validated, create a final release tag and push it. We also need to merge the release branch back into master as a final step.

git checkout release/v0.X.0
git tag -as v0.X.0 -m "final release." (use v0.X.0-beta as the tag if you are creating a beta release)
git push origin v0.X.0
git switch master
git pull
git merge release/v0.X.0

Update waku-rust-bindings, waku-simulator and nwaku-compose to use the new release.
Create a GitHub release from the release tag.
- Add binaries produced by the "Upload Release Asset" workflow. Where possible, test the binaries before uploading to the release.

After the release

Announce the release on Twitter, Discord and other channels.
Deploy the release image to Dockerhub by triggering the manual Jenkins deployment job.

Ensure the following build parameters are set:

MAKE_TARGET: wakunode2

IMAGE_TAG: the release tag (e.g. v0.36.0)

IMAGE_NAME: wakuorg/nwaku

NIMFLAGS: --colors:off -d:disableMarchNative -d:chronicles_colors:none -d:postgres

GIT_REF the release tag (e.g. v0.36.0)

Performing a patch release

Cherry-pick the relevant commits from master to the release branch
```
git cherry-pick <commit-hash>
```
Create a release-candidate tag with the same name as release and -rc.N suffix
Update CHANGELOG.md. From the release branch, use the helper Make target after having cherry-picked the commits.
```
make release-notes
```
Create a new branch and raise a PR with the changelog updates to master.
Once the release-candidate has been validated and changelog PR got merged, cherry-pick the changelog update from master to the release branch. Create a final release tag and push it.
Create a GitHub release from the release tag and follow the same post-release process as usual.

8.0 KiB Raw Permalink Blame History