$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.

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
    
  • Create a Security release approval issue and post a message in the #security channel tagging @security-support.

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 this 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.

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:

  • 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:
  • 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

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.