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. 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_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
- `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.

## 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).