$MAJOR.$MINOR release

This release is scheduled for $RELEASE_DATE.

Setup

Ensure release configuration in dev/release/release-config.jsonc on main is up to date with the parameters for the current release.
Ensure you have the latest version of the release tooling and configuration by checking out and updating sourcegraph@main.

Security review (one week before release - $ONE_WORKING_WEEK_BEFORE_RELEASE)

Create a new issue using the Security release approval template and post a message in the #security channel tagging @security-support.

Cut release (three days before release - $THREE_WORKING_DAY_BEFORE_RELEASE)

Perform these steps three days before the release date to generate a stable release candidate.

Prepare release

Post a release status update to Slack - review all release-blocking issues, and ensure someone is resolving each.
```
yarn release release:status
```

Do the branch cut for the release:

Update the changelog and create pull requests:
```
yarn release changelog:cut
```
Manually review the pull requests created in the previous step and merge.
Create the $MAJOR.$MINOR branch off the CHANGELOG commit in the previous step:
```
yarn release release:branch-cut
```
To support the multi-version upgrade utility, update the maxVersionString constant to $MAJOR.$MINOR.0 on the main branch, then cherry-pick this change into the $MAJOR.$MINOR branch. Bumping this version will require the $MAJOR.$MINOR branch to exist, and go generate will need to be invoked (example).

Upon branch cut, create and test release candidates:

Tag the first release candidate:

N=1; yarn release release:create-candidate $N

Ensure that the following Buildkite pipelines all pass for the v$MAJOR.$MINOR.$PATCH-rc.N tag:
- Sourcegraph pipeline
Corss check all reported CVEs are in the accepted list (https://handbook.sourcegraph.com/departments/security/tooling/trivy/$MAJOR-$MINOR-$PATCH). Otherwise, alert @security-support in the #release-guild channel ASAP.
File any failures and regressions in the pipelines as release-blocker issues and assign the appropriate teams.

Revert or disable features that may cause delays. As necessary, git cherry-pick bugfix (not feature!) commits from main into the release branch. Continue to create new release candidates as necessary, until no more release-blocker issues remain.

Note: You will need to re-check the above pipelines for any subsequent release candidates. You can see the Buildkite logs by tweaking the “branch” query parameter in the URLs to point to the desired release candidate. In general, the URL scheme looks like the following (replacing N in the URL):

Sourcegraph: https://buildkite.com/sourcegraph/sourcegraph/builds?branch=v$MAJOR.$MINOR.$PATCH-rc.N
Post a release status update to Slack:
```
yarn release release:status
```
Edit the following message to reflect the correct release candidate number, and post the message to the #cloud channel asking for the release candidate to be deployed to a test managed instance. You’re good to go once the instance is up and running:
```
Hey team, I'm the release captain for the $MAJOR.$MINOR release, posting here for asking for a release candidate (v$MAJOR.$MINOR.$PATCH-rc.N) to be deployed to a test managed instance. Could someone help here? :ty:
```

Release day ($RELEASE_DATE)

Stage release

On the day of the release, confirm there are no more release-blocking issues (as reported by the release:status command), then proceed with creating the final release:

Make sure CHANGELOG entries have been moved from Unreleased to $MAJOR.$MINOR.$PATCH, but exluding the ones that merged to main after the branch cut (whose changes are not in the $MAJOR.$MINOR branch).
Make sure deploy-sourcegraph-helm CHANGELOG entries have been moved from Unreleased to $MAJOR.$MINOR.$PATCH, but exluding the ones that merged to main after the branch cut (whose changes are not in the $MAJOR.$MINOR branch).

Tag the final release:

yarn release release:create-candidate final

Ensure that the following pipelines all pass for the v$MAJOR.$MINOR.$PATCH tag:
- Sourcegraph pipeline
Wait for the v$MAJOR.$MINOR.$PATCH release Docker images to be available in Docker Hub
Open PRs that publish the new release and address any action items required to finalize draft PRs (track PR status via the generated release batch change):
```
yarn release release:stage
```

Finalize release

From the release batch change, merge the release-publishing PRs created previously.
- For sourcegraph
  - Cherry pick the release-publishing PR from sourcegraph/sourcegraph@main into the release branch.
- For deploy-sourcegraph
  - Ensure the release tag v$MAJOR.$MINOR.$PATCH has been created
- For deploy-sourcegraph-docker
  - Ensure the release tag v$MAJOR.$MINOR.$PATCH has been created
- For deploy-sourcegraph-helm
  - Cherry pick the release-publishing PR from the release branch into main
Alert the marketing team in #release-post that they can merge the release post.
Finalize and announce that the release is live:
```
yarn release release:announce
```

Post-release

Notify the next release captain that they are on duty for the next release.
Open a PR to update dev/release/release-config.jsonc with the parameters for the next release.
- Change upcomingRelease to the current patch release
- Change previousRelease to the previous patch release version
- Change releaseDate to the current date (time is optional) along with oneWorkingDayAfterRelease and threeWorkingDaysBeforeRelease
- Change captainSlackUsername and captainGitHubUsername accordingly
Ensure you have the latest version of the release tooling and configuration by checking out and updating sourcegraph@main.
Create release calendar events, tracking issue, and announcement for next release:
```
yarn run release tracking:issues
yarn run release tracking:timeline
```
Close the release.
```
yarn run release release:close
```

Note: If a patch release is requested after the release, ask that a patch request issue be filled out and approved first.