Skip to content

Release Instructions

Cherry-Picking Fixes

✋ Before you start, make sure you have created a release branch (e.g. release-3.3) and it's passing CI. Please make sure that all patch releases (e.g. v3.3.5) should be released from their associated minor release branches (e.g. release-3.3) to work well with our versioned website.

Then get a list of commits you may want to cherry-pick:

./hack/cherry-pick.sh release-3.3 "fix"
./hack/cherry-pick.sh release-3.3 "chore(deps)"
./hack/cherry-pick.sh release-3.3 "build"
./hack/cherry-pick.sh release-3.3 "ci"

To automatically cherry-pick, run the following:

./hack/cherry-pick.sh release-3.3 "fix" false

Then look for "failed to cherry-pick" in the log to find commits that fail to be cherry-picked and decide if a manual patch is necessary.

Ignore:

  • Fixes for features only on main.
  • Dependency upgrades, unless they fix known security issues.
  • Build or CI improvements, unless the release pipeline is blocked without them.

Cherry-pick the first commit. Run make test locally before pushing. If the build timeouts the build caches may have gone, try re-running.

Don't cherry-pick another commit until the CI passes. It is harder to find the cause of a new failed build if the last build failed too.

Cherry-picking commits one-by-one and then waiting for the CI will take a long time. Instead, cherry-pick each commit then run make test locally before pushing.

Publish Release

✋ Before you start, make sure the branch is passing CI.

Push a new tag to the release branch. E.g.:

git tag v3.3.4
git push upstream v3.3.4 # or origin if you do not use upstream

GitHub Actions will automatically build and publish your release. This takes about 1h. Set your self a reminder to check this was successful.

Update Changelog and Tested Versions

Once the tag is published, GitHub Actions will automatically open two PRs:

  1. PR against the main branch to update the changelog.
  2. PR against the release branch to update the "Tested Versions" table.

Once the PRs are ready, you can approve them, enable auto-merge, and then run the following to force trigger the CI build:

git branch -D create-pull-request/changelog
git fetch upstream
git checkout --track upstream/create-pull-request/changelog
git commit -s --allow-empty -m "chore: Force trigger CI"
git push upstream create-pull-request/changelog

Announce on Slack

Once the changelog updates have been merged, you should announce on our Slack channels, #argo-workflows and #argo-announcements. See previous announcements as examples of what to write in the patch announcement.

Have a question?

Search on GitHub Discussions and Slack.