Cutting a Deno release

Pre-flight checklist

• An up to date stable Rust toolchain
• A binary version of deno available (hopefully built from main) that is going to be available throughout any local building you might do.
• Forks and local clones of denoland/deno, denoland/deno_std, denoland/dotland, denoland/docland, denoland/deno_docker denoland/manual
• Ensure that external dependencies are up-to date in denoland/deno (e.g. rusty_v8, serde_v8, deno_doc, deno_lint).
• Lot’s of ☕

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.

Before starting the process write a message in company’s #general channel: :lock: deno and deno_std are now locked

Updating deno_std

1. Go to the “version_bump” workflow in the deno_std repo’s actions: https://github.com/denoland/deno_std/actions/workflows/version_bump.yml

2. Click on the “Run workflow” button.

   1. For the kind of release, select “minor”.
   2. Run the workflow.

3. A PR will be automatically created. Follow the checklist in the PR and review it.

   ❌ Failure Steps

   1. Checkout the latest main.
   2. Manually run ./_tools/release/01_bump_version.ts --minor
      1. Ensure the version in version.ts is updated correctly.
      2. Ensure Releases.md is updated correctly.
      3. Ensure all the tests pass with the latest build (examine the repo for what the command is and run the local built deno binary)
   3. Open a PR with the changes and continue with the steps below.

Updating the main repo

If you are cutting a patch release: First you need to sync commit to the relevant minor branch, so if you are cutting a v1.17.3 release you need to sync v1.17 branch.

To do that, you need to cherry-pick commits from the main branch to the v1.17 branch. For patch releases we want to cherry-pick all commits that do not add features to the CLI. This generally means to filter out feat commits but not necessarily (ex. feat(core): ...). Check what was the last commit on v1.17 branch before the previous release and start cherry-picking newer commits from the main.

Once all relevant commits are cherry-picked, push the branch to the upstream and verify on GitHub that everything looks correct.

Phase 1: Bumping versions

1. After releasing deno_std, go to the “version_bump” workflow in the CLI repo’s actions: https://github.com/denoland/deno/actions/workflows/version_bump.yml

2. Click on the “Run workflow” button.

   1. In the drop down, select the minor branch if doing a patch release or the main branch if doing a minor release.
   2. For the kind of release, select either “patch”, “minor”, or “major”.
   3. Run the workflow.

3. Wait for the workflow to complete and for a pull request to be automatically opened.

   ❌ Failure Steps

   1. Checkout the branch the release is being made on.
   2. Manually run ./tools/release/01_bump_crate_versions.ts
      1. Ensure the crate versions were bumped correctly
      2. Ensure deno_std version was updated correctly in cli/compat/mod.rs
      3. Ensure Releases.md was updated correctly
   3. Open a PR with the changes and continue with the steps below.

Phase 2: Publish

1. Go to the “cargo_publish” workflow in the CLI repo’s actions: https://github.com/denoland/deno/actions/workflows/cargo_publish.yml

2. Run it on the same branch that you used before and wait for it to complete.

   ❌ Failure Steps

   1. The workflow was designed to be restartable. Try restarting it.
   2. If that doesn’t work, then do the following:
      1. Checkout the branch the release is occurring on.
      2. If cargo publish hasn’t completed then run ./tools/release/03_publish_crates.ts
         • Note that you will need access to crates.io so it might fail.
      3. If cargo publish succeeded and a release tag wasn’t created, then manually create and push one for the release branch with a leading v.

cargo build --release
cd target/release
zip -r deno-aarch64-apple-darwin.zip deno

Updating doc.deno.land

This should occur after the Deno CLI is fully published, as the build script queries the GitHub API to determine what it needs to change and update.

1. Goto the cloned report for denoland/docland.

2. Checkout a new branch (e.g. git checkout -b deno_1.17.0).

3. Execute deno task build

4. Commit changes and raise a PR on denoland/docland.

5. Merging the approved PR will trigger deployment to Deploy of the updates.

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

Write a message in company’s #general channel: 🔓 deno and deno_std are now unlocked.