Open Match Release Process

Follow these instructions to create an Open Match release. The output of the release process is new images and new configuration.

Getting setup

NOTE: The instructions below are NOT strictly copy-pastable and assume 0.5 release. Please update the version number for your commands.

The Git flow for pushing a new release is similar to the development process but there are some small differences.

1. Clone Repository

# Clone your fork of the Open Match repository.
git clone git@github.com:afeddersen/open-match.git
# Change directory to the git repository.
cd open-match
# Add a remote, you'll be pushing to this.
git remote add upstream https://github.com/googleforgames/open-match.git

2. Release Branch

If you're creating the first release of the version, that would be 0.5.0-rc.1 then you'll need to create the release branch.

# Create a local release branch.
git checkout -b release-0.5 upstream/main
# Push the branch upstream.
git push upstream release-0.5

otherwise there should already be a release-0.5 branch so run,

# Checkout the release branch.
git checkout -b release-0.5 upstream/release-0.5

NOTE: The branch name must be in the format, release-X.Y otherwise some artifacts will not be pushed.

Releases & Versions

Open Match uses Semantic Versioning 2.0.0. If you're not familiar please see the documentation - https://semver.org/.

Full Release / Stable Release:

The final software product. Stable, reliable, etc...
Example: 1.0.0, 1.1.0

Release Candidate (RC):

A release candidate (RC) is a version with the potential to be the final product but it hasn't validated by automated and/or manual tests.
Example: 1.0.0-rc.1

Hot Fixes:

Code developed to correct a major software bug or fault that's been discovered after the full release.
Example: 1.0.1

Preview:

Rare, a one off release cut from the main branch to provide early access to APIs or some other major change.
NOTE: There's no branch for this release.
Example: 0.5-preview.1

NOTE: Semantic versioning is enforced by go mod. A non-compliant version tag will cause go get to break for users.

Detailed Instructions

Find and replace

Below this point you will see {version} used as a placeholder for future releases. Find {version} and replace with the current release (e.g. 0.5.0)

Create a release branch in the upstream open-match repository

Note: This step is performed by the person who starts the release. It is only required once.

[x] Create the branch in the upstream repository. It should be named release-X.Y. Example: release-0.5. At this point there's effectively a code freeze for this version and all work on main will be included in a future version. If you're on the branch that you created in the getting setup section above you should be able to push upstream.

git push origin release-0.5

[x] Announce a PR freeze on release-X.Y branch on open-match-discuss@.
[x] Open the Makefile and change BASE_VERSION entry.
[x] Open the install/helm/open-match/Chart.yaml and change the appVersion and version entries.
[x] Open the install/helm/open-match/values.yaml and change the tag entries.
[x] Open the [cloudbuild.yaml] and change the _OM_VERSION entry.
[x] There might be additional references to the old version but be careful not to change it for places that have it for historical purposes.
[x] Update usage requirements in the Installation doc - e.g. supported minikube version, kubectl version, golang version, etc.
[x] Create a PR with the changes, include the release candidate name, and point it to the release branch.
[x] Go to open-match-build and update all post submit triggers' _GCB_LATEST_VERSION value to the X.Y of the release. This value should only increase as it's used to determine the latest stable version.
[x] Merge your changes once the PR is approved. Note: the helm chart is not published to the public registry until the merge is complete (it's a second cloud build trigger upon merge), so you won't be able to do final release testing until after all checks/approvals are finished!

Create a release branch in the upstream open-match-docs repository

[x] Open Makefile and change BASE_VERSION entry.
[x] Open [cloudbuild.yaml] and change the _OM_VERSION entry.
[x] Open [site/config.toml] and change the release_version entry.
[x] Open [site/static/swaggerui/config.json] and change the api/VERSION/... entries
[ ] Create a PR with the changes, include the release candidate name, and point it to the release branch.

Complete Milestone