1# Zed Releases
2
3Read about Zed's release channels [here](https://zed.dev/faq#what-are-the-release-channels).
4
5## Wednesday release process
6
7You will need write access to the Zed repository to do this.
8
9Credentials for various services used in this process can be found in 1Password.
10
11---
12
131. Checkout `main` and ensure your working copy is clean.
14
151. Run `git fetch && git pull` to ensure you have the latest commits locally.
16
171. Run `git fetch --tags --force` to forcibly ensure your local tags are in sync with the remote.
18
191. Run `./script/get-stable-channel-release-notes`.
20
21 - Follow the instructions at the end of the script and aggregate the release notes into one structure.
22
231. Run `./script/bump-zed-minor-versions`.
24
25 - Push the tags and branches as instructed.
26
271. Run `./script/get-preview-channel-changes`.
28
29 - Take the script's output and build release notes by organizing each release note line into a category.
30 - Use a prior release for the initial outline.
31 - Make sure to append the `Credit` line, if present, to the end of the release note line.
32
331. Once release drafts are up on [GitHub Releases](https://github.com/zed-industries/zed/releases), paste both preview and stable release notes into each and **save**.
34
35 - **Do not publish the drafts, yet.**
36
371. Check the release assets.
38
39 - Ensure the stable and preview release jobs have finished without error.
40 - Ensure each build has the proper number of assets—releases currently have 10 assets each.
41 - Download the artifacts for each release and test that you can run them locally.
42
431. Publish each build, one at a time.
44
45 - Use [Vercel](https://vercel.com/zed-industries/zed-dev) to check the status of each build.
46
471. Publish the release email that has been sent to [Kit](https://kit.com).
48
49 - Make sure to double check that the email is correct before publishing.
50 - We sometimes correct things here and there that didn't translate from GitHub's renderer to Kit's.
51
521. Build social media posts based on the popular items in stable.
53
54 - You can use the [prior week's post chain](https://zed.dev/channel/tweets-23331) as your outline.
55 - Stage the copy and assets using [Buffer](https://buffer.com), for both X and BlueSky.
56 - Publish both, one at a time, ensuring both are posted to each respective platform.
57
58## Patch release process
59
60If 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.
61
62You will need write access to the Zed repository to do this:
63
64- Send a PR containing your change to `main` as normal.
65- 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.
66 - In case of a merge conflict, you will have to cherry-pick manually and push the change to the `v0.XXX.x` branch.
67- 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.
68 - This can also be run from the [GitHub Actions UI](https://github.com/zed-industries/zed/actions/workflows/bump_patch_version.yml):
69 
70- Wait for the builds to appear on [the Releases tab on GitHub](https://github.com/zed-industries/zed/releases) (typically takes around 30 minutes)
71- Proof-read and edit the release notes as needed.
72- Download the artifacts for each release and test that you can run them locally.
73- Publish the release.
74
75## Nightly release process
76
77In addition to the public releases, we also have a nightly build that we encourage employees to use.
78Nightly 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`.