Zed Releases

Read about Zed's release channels here.

Wednesday release process

You will need write access to the Zed repository to do this.

Credentials for various services used in this process can be found in 1Password.

  1. Checkout main and ensure your working copy is clean.

  2. Run git fetch && git pull to ensure you have the latest commits locally.

  3. Run git fetch --tags --force to forcibly ensure your local tags are in sync with the remote.

  4. Run ./script/get-stable-channel-release-notes.

    • Follow the instructions at the end of the script and aggregate the release notes into one structure.

  5. Run ./script/bump-zed-minor-versions.

    • Push the tags and branches as instructed.

  6. Run ./script/get-preview-channel-changes.

    • Take the script's output and build release notes by organizing each release note line into a category.
    • Use a prior release for the initial outline.
    • Make sure to append the Credit line, if present, to the end of the release note line.

  7. Once release drafts are up on GitHub Releases, paste both preview and stable release notes into each and save.

    • Do not publish the drafts, yet.

  8. Check the release assets.

    • Ensure the stable and preview release jobs have finished without error.
    • Ensure each draft has the proper number of assets—releases currently have 10 assets each.
    • Download the artifacts for each release draft and test that you can run them locally.

  9. Publish stable / preview drafts, one at a time.

    • Use Vercel to check the progress of the website rebuild. The release will be public once the rebuild has completed.

  10. Publish the release email that has been sent to Kit.

    • Make sure to double-check that the email is correct before publishing.
    • We sometimes correct things here and there that didn't translate from GitHub's renderer to Kit's.

  11. Build social media posts based on the popular items in stable.

    • You can use the prior week's post chain as your outline.
    • Stage the copy and assets using Buffer, for both X and BlueSky.
    • Publish both, one at a time, ensuring both are posted to each respective platform.

Patch release process

If your PR fixes a panic or a crash, you should cherry-pick it to the current stable and preview branches. If your PR fixes a regression in recently released code, you should cherry-pick it to preview.

You will need write access to the Zed repository to do this:

  1. Send a PR containing your change to main as normal.

  2. Once it is merged, cherry-pick the commit locally to either of the release branches (v0.XXX.x).

    • In some cases, you may have to handle a merge conflict. More often than not, this will happen when cherry-picking to stable, as the stable branch is more "stale" than the preview branch.

  3. After the commit is cherry-picked, run ./script/trigger-release {preview|stable}. This will bump the version numbers, create a new release tag, and kick off a release build.

  4. Once release drafts are up on GitHub Releases, proofread and edit the release notes as needed and save.

    • Do not publish the drafts, yet.

  5. Check the release assets.

    • Ensure the stable / preview release jobs have finished without error.
    • Ensure each draft has the proper number of assets—releases currently have 10 assets each.
    • Download the artifacts for each release draft and test that you can run them locally.

  6. Publish stable / preview drafts, one at a time.

    • Use Vercel to check the progress of the website rebuild. The release will be public once the rebuild has completed.

Nightly release process

In addition to the public releases, we also have a nightly build that we encourage employees to use. Nightly is released by cron once a day, and can be shipped as often as you'd like. There are no release notes or announcements, so you can just merge your changes to main and run ./script/trigger-release nightly.