1# Zed Releases
2
3Zed currently maintains two public releases for macOS:
4
5- [Stable](https://zed.dev/download): This is the primary version that people download and use.
6- [Preview](https://zed.dev/releases/preview): which receives updates a week ahead of Stable for early adopters.
7
8Typically we cut a new minor release every Wednesday. The current Preview becomes Stable, and the new Preview contains everything on main up until that point.
9
10If bugs are found and fixed during the week, they may be cherry-picked into the release branches and so new patch versions for preview and stable can become available throughout the week.
11
12## Wednesday release process
13
14You will need write access to the Zed repository to do this:
15
16- Checkout `main` and ensure your working copy is clean.
17- Run `./script/bump-zed-minor-versions` and push the tags
18 and branches as instructed.
19- Wait for the builds to appear on [the Releases tab on GitHub](https://github.com/zed-industries/zed/releases) (typically takes around 30 minutes)
20- While you're waiting:
21 - Start creating the new release notes for preview. You can start with the output of `./script/get-preview-channel-changes`.
22 - Start drafting the release tweets.
23- Once the builds are ready:
24 - Copy the release notes from the previous Preview release(s) to the current Stable release.
25 - Download the artifacts for each release and test that you can run them locally.
26 - Publish the releases on GitHub.
27 - Tweet the tweets (Credentials are in 1Password).
28
29## Patch release process
30
31If 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.
32
33You will need write access to the Zed repository to do this:
34
35- Send a PR containing your change to `main` as normal.
36- Leave a comment on the PR `/cherry-pick v0.XXX.x`. Once your PR is merged, the GitHub bot will send a PR to the branch.
37 - In case of a merge conflict, you will have to cherry-pick manually and push the change to the `v0.XXX.x` branch.
38- After the commits are cherry-picked onto the branch, run `./script/trigger-release {preview|stable}`. This will bump the version numbers, create a new release tag, and kick off a release build.
39 - This can also be run from the [GitHub Actions UI](https://github.com/zed-industries/zed/actions/workflows/bump_patch_version.yml):
40 
41- Wait for the builds to appear on [the Releases tab on GitHub](https://github.com/zed-industries/zed/releases) (typically takes around 30 minutes)
42- Proof-read and edit the release notes as needed.
43- Download the artifacts for each release and test that you can run them locally.
44- Publish the release.
45
46## Nightly release process
47
48In addition to the public releases, we also have a nightly build that we encourage employees to use.
49Nightly 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`.