denoland-deno/tools/cut_a_release.md

Cutting a Deno release

During this process main branch (or any other branch that you're creating release from) should be frozen and no commits should land until the release is cut.

Updating deno_std

1. Open a PR on the deno_std repo that bumps the version in version.ts and updates Releases.md

2. Before merging the PR, make sure that all tests pass when run using binary produced from bumping crates (point 3. from below).

3. Create a tag with the version number (without v prefix).

Updating the main repo

1. Create a PR that bumps versions of all crates in extensions and runtime directories.

To determine if you should bump a crate a minor version instead of a patch version, check if you can answer any of the following questions with yes:

• Did any of the crates direct dependencies have a semver breaking change? For example did we update swc_ecmascript from 0.56.0 to 0.57.0, or did we update rusty_v8?
• Did the external interface of the crate change (ops or changes to window.__bootstrap in JS code)?

When in doubt always do a minor bump instead of a patch. In essentially every release all crates will need a minor bump. Patch bumps are the exception, not the norm.

2. Make sure CI pipeline passes.

3. Publish all bumped crates to crates.io

Make sure that cargo is logged on with a user that has permissions to publish those crates.

This is done by running cargo publish in each crate, because of dependencies between the crates, it must be done in specific order:

• deno_core - all crates depend on deno_core so it must always be published first
• bench_util
• crates in extensions/ directory
  • deno_net, deno_websocket and deno_fetch depend on deno_tls, so the latter must be bumped and released first
  • deno_fetch, deno_crypto, deno_timers and deno_webstorage depend on deno_web, so the latter must be bumped and released first
  • deno_url depends on deno_webidl, so the latter must be bumped and released first
  • deno_timers depends on deno_url, so the latter must be bumped and released first
  • deno_http depends on deno_websocket, so the latter must be bumped and released first
• runtime - this crate depends on deno_core and all crates in extensions/ directory

If there are any problems when you publish, that require you to change the code, then after applying the fixes they should be commited and pushed to the PR.

4. Once all crates are published merge the PR.

5. Create a PR that bumps cli crate version and updates Releases.md.

6. Make sure CI pipeline passes.

7. Publish cli crate to crates.io

8. Merge the PR.

9. Create a tag with the version number (with v prefix).

10. Wait for CI pipeline on the created tag branch to pass.

The CI pipeline will create a release draft on GitHub (https://github.com/denoland/deno/releases).

11. Upload Apple M1 build to the release draft & to dl.deno.land.

12. Publish the release on Github

13. Update the Deno version on the website by updating https://github.com/denoland/deno_website2/blob/main/versions.json.

14. Push a new tag to manual. The tag must match the tag from point 9; you don't need to create dedicated commit for that purpose, it's enough to tag the latest commit in that repo.

Updating deno_docker

1. Open a PR on the deno_docker repo that bumps the Deno version in all Dockerfiles, the README and the example Dockerfile
2. Create a tag with the version number (without v prefix).