$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 (day before release - $ONE_WORKING_DAY_BEFORE_RELEASE)

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

Prepare release

Do the branch cut for the release:

  • Update the changelog and merge the generated pull request:
    yarn release changelog:cut
    
  • Create the $MAJOR.$MINOR branch off the CHANGELOG commit in the previous step:
    git branch $MAJOR.$MINOR && git push origin $MAJOR.$MINOR
    

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.1 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
    
  • Post in #cloud-devops channel asking for release candidate to be deployed to a test managed instance

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:

  • Verify the CHANGELOG on main and $MAJOR.$MINOR are accurate.

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

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