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
11Use the `releases` Slack channel to notify the team that releases will be starting.
12This is mostly a formality on Wednesday's minor update releases, but can be beneficial when doing patch releases, as other devs may have landed fixes they'd like to cherry pick.
13
14---
15
161. Checkout `main` and ensure your working copy is clean.
17
181. Run `git fetch && git pull` to ensure you have the latest commits locally.
19
201. Run `git fetch --tags --force` to forcibly ensure your local tags are in sync with the remote.
21
221. Run `./script/get-stable-channel-release-notes`.
23
24 - Follow the instructions at the end of the script and aggregate the release notes into one structure.
25
261. Run `./script/bump-zed-minor-versions`.
27
28 - Push the tags and branches as instructed.
29
301. Run `./script/get-preview-channel-changes`.
31
32 - Take the script's output and build release notes by organizing each release note line into a category.
33 - Use a prior release for the initial outline.
34 - Make sure to append the `Credit` line, if present, to the end of the release note line.
35
361. 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**.
37
38 - **Do not publish the drafts!**
39
401. Check the release assets.
41
42 - Ensure the stable and preview release jobs have finished without error.
43 - Ensure each draft has the proper number of assets—releases currently have 10 assets each.
44 - Download the artifacts for each release draft and test that you can run them locally.
45
461. Publish the drafts.
47
48 - Publish stable and preview drafts, one at a time.
49 - Use [Vercel](https://vercel.com/zed-industries/zed-dev) to check the progress of the website rebuild.
50 The release will be public once the rebuild has completed.
51
521. Post the stable release notes to social media.
53
54 - Bluesky and X posts will already be built as drafts in [Buffer](https://buffer.com).
55 - Publish both, one at a time, ensuring both are posted to each respective platform.
56
571. Send the stable release notes email.
58
59 - The email broadcast will already be built as a draft in [Kit](https://kit.com).
60
611. Build social media posts based on the popular items in preview.
62
63 - Draft the copy in the [tweets](https://zed.dev/channel/tweets-23331) channel.
64 - Create the preview media (videos, screenshots).
65 - For features that you film videos around, try to create alternative photo-only versions to be used in the email, as videos and GIFs aren't great for email.
66 - Store all created media in `Feature Media` in our Google Drive.
67 - Build X and Bluesky post drafts (copy and media) in [Buffer](https://buffer.com), to be sent for next week's stable release.
68
69 **Note: These are preview items and you may discover bugs.**
70 **This is a very good time to report these findings to the team!**
71
721. Build email based on the popular items in preview.
73
74 - You can reuse the copy and photo media from the preview social media posts.
75 - Create a draft email in [Kit](https://kit.com), to be sent for next week's stable release.
76
77## Patch Release Process
78
79If your PR fixes a panic or a crash, you should cherry-pick it to the current stable and preview branches.
80If your PR fixes a regression in recently released code, you should cherry-pick it to preview.
81
82You will need write access to the Zed repository to do this:
83
84---
85
861. Send a PR containing your change to `main` as normal.
87
881. Once it is merged, cherry-pick the commit locally to either of the release branches (`v0.XXX.x`).
89
90 - In some cases, you may have to handle a merge conflict.
91 More often than not, this will happen when cherry-picking to stable, as the stable branch is more "stale" than the preview branch.
92
931. After the commit is cherry-picked, run `./script/trigger-release {preview|stable}`.
94 This will bump the version numbers, create a new release tag, and kick off a release build.
95
96 - This can also be run from the [GitHub Actions UI](https://github.com/zed-industries/zed/actions/workflows/bump_patch_version.yml):
97 
98
991. Once release drafts are up on [GitHub Releases](https://github.com/zed-industries/zed/releases), proofread and edit the release notes as needed and **save**.
100
101 - **Do not publish the drafts, yet.**
102
1031. Check the release assets.
104
105 - Ensure the stable / preview release jobs have finished without error.
106 - Ensure each draft has the proper number of assets—releases currently have 10 assets each.
107 - Download the artifacts for each release draft and test that you can run them locally.
108
1091. Publish stable / preview drafts, one at a time.
110 - Use [Vercel](https://vercel.com/zed-industries/zed-dev) to check the progress of the website rebuild.
111 The release will be public once the rebuild has completed.
112
113## Nightly release process
114
115In addition to the public releases, we also have a nightly build that we encourage employees to use.
116Nightly is released by cron once a day, and can be shipped as often as you'd like.
117There are no release notes or announcements, so you can just merge your changes to main and run `./script/trigger-release nightly`.