2.6 KiB
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.
- Create a PR that bumps versions of all crates in
extensions
andruntime
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.
-
Make sure CI pipeline passes.
-
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:
serde_v8
-deno_core
depends on it, but this crate shouldn't change that often, so you might want to skip publishing a new version if there are no changesdeno_core
- all crates depend ondeno_core
so it must always be published firstbench_util
- crates in
extensions/
directorydeno_crypto
anddeno_webstorage
depend ondeno_web
, so the latter must be bumped and released firstdeno_fetch
depends ondeno_file
, so the latter must be bumped and released first
runtime
- this crate depends ondeno_core
and all crates inextensions/
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.
-
Once all crates are published merge the PR.
-
Create a PR that bumps
cli
crate version and updatesReleases.md
. -
Make sure CI pipeline passes.
-
Publish
cli
crate tocrates.io
-
Merge the PR.
-
Create a tag with the version number (with
v
prefix). -
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).
-
Upload Apple M1 build to the release draft & to dl.deno.land.
-
Publish the release on Github
-
Update the Deno version on the website by updating https://github.com/denoland/deno_website2/blob/main/versions.json.