Deno 版本发布全解：从 2018 年 Golang 原型到 2.9.6，读懂 Releases.md 变更日志背后的版本体系与发布流程

Deno 仓库根目录下的 Releases.md 是一份长达 1.2 万余行、收录 382 个版本条目的完整发布记录，覆盖了从 2018.05.14 的 Go 原型到当前 2.9.6（2026.08.27）的全部版本演进。本文以这份文档为主体，讲解它的组织结构、条目书写规范与阅读方法，并结合 tools/release/ 目录下的发布脚本与 发布检查单模板，说明这份日志是如何被自动化流程生成、校验与回滚的，帮助你在排查行为变更、选择稳定版本和理解 Deno 技术路线时直接把它当作可检索的第一手资料。

一、这份文档是什么：版本与日期的双重索引

Releases.md 开头说明了两个获取发行版的方式：二进制发行版可在官方 Releases 页面手动下载，另外官方安装仓库提供了一行安装命令（macOS/Linux 下为 curl -fsSL https://deno.land/install.sh | sh，Windows PowerShell 下为 irm https://deno.land/install.ps1 | iex，与 README 中的安装指引一致）。除此之外，文档本体是一个倒序排列的变更日志（changelog），每个版本一个 H3 小节，标题格式为：

### <版本号> / <发布日期 YYYY.MM.DD>

当前仓库中 cli/lib/version.txt 的内容是 2.9.6，与文档首条记录 ### 2.9.6 / 2026.08.27 完全对应，可以确认该文档与源码版本保持同步维护。

文档末尾保留了项目最早的历史，标题格式略有变化，带有阶段注记：

条目	位置	说明
### 2.9.6 / 2026.08.27	Releases.md#L9	最新稳定版
### 2.0.0 / 2024.10.09	Releases.md#L5015	2.x 大版本起点，条目多达 300 余行
### v0.25.0 / 2019.11.26	Releases.md#L11988	0.x 时代末期
### v0.2.0 / 2018.11.27 / Mildly usable	Releases.md#L12781	早期版本带口语化阶段注记
### v0.1.0 / 2018.08.23 / Rust rewrite and V8 snapshot	Releases.md#L12961	Rust 重写 + V8 快照
### v0.0.0 / 2018.05.14 - 2018.06.22 / Golang Prototype	Releases.md#L12979	Go 语言原型阶段
### 2007-2017 / Prehistory	Releases.md#L12987	项目诞生前的背景

一个值得注意的细节是版本号书写习惯的变化：0.x 时代标题带 v 前缀（v0.25.0），而 2.x 系列统一去掉了前缀（2.9.6）。部分重要版本还会在标题下方附一句指向官方博客的 “Read more” 提示，例如 2.9.0 小节就有一条这样的指引（见 Releases.md#L489-L491）。

二、条目书写规范：feat / fix / perf 三段式与 PR 溯源

每个版本小节内部是一个无序列表，条目遵循统一的语义化前缀格式：

- feat(作用域): 功能描述 (#PR 编号)
- fix(作用域): 修复描述 (#PR 编号)
- perf(作用域): 性能优化描述 (#PR 编号)

以 2.9.6（Releases.md#L9-L103）为例，条目包括 feat(compressible): add support for 'text/x-component' content type (#36450)、fix(ext/fetch): raise default HTTP/2 SETTINGS_MAX_HEADER_LIST_SIZE to 256KB (#36558)、perf(core): zero-copy snapshot rehydration, drop bincode (#36680) 等。这种格式带来两个直接好处：

1. 可溯源：每条变更都带 PR 编号，可据此定位完整的提交、评审与测试记录；
2. 可检索：grep 'fix(ext/http)' Releases.md 这类操作可以直接拉出某个模块的全部修复历史。

从源码结构看，括号中的 scope 与仓库目录高度对应：fix(core) 对应 libs/core/、fix(ext/net) 对应 ext/net/、fix(ext/node) 对应 ext/node/ 的 Node 兼容层、fix(desktop) 对应 cli/rt_desktop/ 与 cli/tools/desktop.rs、fix(npm) 对应 libs/npm/ 与 libs/npm_installer/ 等包管理实现。因此当你遇到某个 API 的异常行为时，按 scope 检索这份日志往往比逐条读文档更快。

用变更日志做“行为变更”排障的示例

文档中大量条目描述的是权限与安全边界的收紧，这类条目对升级决策影响最大。例如：

• 2.9.5：fix(ext/net): require --allow-sys for node:dns.getServers() (#35941) —— 该 API 从此需要 --allow-sys 权限；
• 2.9.6：fix(fs): require write permission for creating opens (#34497) 与 fix(permissions): check resolved IP against import deny list (#36486)；
• 2.9.0：fix(permissions): require --allow-net for Unix domain socket ops (#34395)。

如果你的脚本在升级后出现权限报错，先在 Releases.md 中搜索相关模块的 fix(permissions)、require 类条目，就能精确定位是哪个版本、哪条 PR 引入了约束。

三、近期重点版本速览

按文档顺序梳理 2.8.x ～ 2.9.x 各版本的关键条目，可以看到近期开发重心：

2.9.x：桌面化、Watch 与 Web 平台 API 补齐

• 2.9.6（2026.08.27）：桌面端持续打磨（菜单项支持 checked/icon/tooltip、剪贴板 API、HMR 开发服务器适配），fetch 层默认 HTTP/2 SETTINGS_MAX_HEADER_LIST_SIZE 提升至 256KB，核心运行时多项线程安全修复（Unix pipe fd 归属、定时器唤醒器线程安全）；
• 2.9.5（2026.08.06）：deno add 新增 --unscoped 标志、deno task 新增 --members、新增 Blob/Body textStream()，并加入实验性 QuickJS 后端（feat: add experimental QuickJS backend (#36194)）；
• 2.9.4（2026.07.23）：升级 V8 到 150.2.0（feat: upgrade V8 to 150.2.0 (#36098)）、Deno.createHttpClient 新增 http2MaxHeaderListSize 选项、deno compile 支持 watch 模式出现在 2.8.3 而 2.9.4 继续修复其 Windows 资源段问题；
• 2.9.3（2026.07.15）：deno add 支持 --no-save/--save-optional，新增 --min-dep-age 别名，compile 支持 aarch64-pc-windows-msvc 目标；
• 2.9.2（2026.07.08）：桌面端 HMR 框架化（Vite、Nuxt、React Router 自动检测），deno test 相关能力增强，Web Streams 大量 perf 条目；
• 2.9.0（2026.06.25）：里程碑版本，条目超过 200 行，核心亮点包括：
  • feat: deno desktop subcommand (#33441) —— 桌面应用运行时正式登场；
  • feat(cli): add deno watch subcommand (#35301)、deno list（列出声明依赖）、deno link/unlink（链接本地包）；
  • feat(ext/web): web locks api (#31166) —— 标准 Web Locks API；
  • feat(test): built-in snapshot testing via t.assertSnapshot (#35139)、Deno.test.each、--shard 测试分片、--changed/--related 增量测试；
  • feat(npm): install jsr deps into node_modules via npm-compat registry (#35029) 等 npm 生态互操作；
  • 性能方面 perf: startup time (22ms -> 15ms) (#34450)，启动时间从 22ms 降至 15ms。

2.8.x：后量子密码与 compile 打包能力

• 2.8.3（2026.06.11）：feat(compile): support watch mode (#34860)、SubtleCrypto.supports()、ML-DSA JWK 导入导出、node:http2 自动接入 OpenTelemetry；
• 2.8.2（2026.06.03）：feat(unstable): add --bundle flag to deno compile (#34527) 开启编译产物打包，WebCrypto 新增 ChaCha20-Poly1305、ML-DSA（FIPS 204）签名与 ML-KEM（FIPS 203）后量子密钥封装，Jupyter kernel 用 JS 重写并移除 zeromq 依赖。

更早的 2.3.0、2.4.0、2.5.0 等版本条目同样完整保留在文档中（分别位于 Releases.md#L3752、Releases.md#L3360、Releases.md#L3089 附近），1.x 时代则可以一直回溯到 1.29.0 附近（Releases.md#L8119）及 2019 年的 0.x 版本，为跨版本升级提供了完整的中间参照。

四、这份日志是如何生成的：tools/release 发布流水线

Releases.md 并非手工逐条维护，仓库中 tools/release/ 目录提供了一套编号化脚本，从脚本命名可以推断出完整流水线：00_start_release.ts → 01_bump_crate_versions.ts → 02_create_pr.ts → 03_publish_crates.ts → 04_post_publish.ts → 05_create_release_notes.ts，另配有 update_versions_json.ts（维护 versions.json 版本索引）与 upload_version_file.ts（上传版本文件）。总入口文档为 tools/cut_a_release.md。

结合 发布检查单模板，一次标准发布的流程是：

1. 分支冻结：发布期间 denoland/deno 主干禁止合入 PR，保证变更集边界清晰——这正是 Releases.md 中每个版本条目范围确定的前提；
2. 版本号提升：触发 version_bump 工作流，其底层调用 01_bump_crate_versions.ts，检查单明确要求“Ensure Releases.md was updated correctly”——即版本标题行与新版本条目由该脚本统一写入；
3. 发布 crate 并打 tag：cargo_publish 工作流执行 03_publish_crates.ts，成功后自动创建 v$VERSION tag（模板特别强调禁止手工打 tag）；
4. 二次 CI 生成发布草稿：tag 触发第二个 CI run，在 GitHub 上生成 release draft，并从版本对比中提取 feat/fix/perf 条目；
5. 产物校验：检查单要求草稿恰好包含 46 个发布资产，且分发端对应该版本有 48 个 zip 文件；
6. 周边同步：更新官网与文档站版本、打 docker 镜像 tag（注意不带 v 前缀）、发布 PyPI 包、必要时更新 MDN browser-compat-data；
7. 可选升级横幅：在分发端上传纯文本 banner.txt，用户执行 deno upgrade（实现位于 cli/tools/upgrade.rs）时会被提示，用于告知破坏性变更或必做操作。

若发布失败，模板也给出了明确的降级路径：将分发端的 release-latest.txt 回指上一个版本，并回滚官网的版本 PR，从而阻断新用户安装到坏版本——这解释了为什么分发端同时存在 “latest 指针” 与完整版本目录两套机制。

五、从日志看 Deno 的演进主线

把 382 个条目纵向读完，有几条清晰的技术主线，全部可以直接在文档中找到证据：

• Node 兼容层持续加厚：fix(ext/node) 是出现频率最高的 scope 之一，从 polyfill 单个模块（如 node:test 的 mock.module、mock.timers、worker_threads.locks）到 feat(node): bump reported process.version to v26.3.0 (#34747)，模拟的 Node 版本随版本递增；
• npm 生态深度整合：2.9.0 的 feat(install): seed deno.lock from package-lock.json/yarn.lock/pnpm-lock.yaml/bun.lock 系列条目表明 Deno 可以基于主流包管理器的锁文件初始化 deno.lock，配合 2.9.6 中 fix(npm): validate tar paths before extraction (#36468) 等安全加固；
• Web 平台 API 对齐：Web Locks、navigator.userAgentData、Deno.watchFs 的 ignore 选项、EventSource HTTP/2 头长度调整等，均指向与浏览器平台的 API 趋同；
• 性能工程化：perf 类条目自 2.x 起密度显著上升，如 2.9.6 的零拷贝快照重建（perf(core): zero-copy snapshot rehydration, drop bincode (#36680)）、2.9.0 的启动时间优化（22ms → 15ms）与 perf(macos): enable chained fixups to cut pre-main startup (~0.8ms) (#35409)，说明启动性能已被当作一等指标管理；
• 安全与权限默认值收紧：如上文第三类排障示例所示，权限类修复在各版本中稳定出现。

六、实践建议：如何高效使用 Releases.md

1. 定位行为变更：升级前后行为不一致时，用 grep 'fix(模块名)' Releases.md 过滤两个版本区间内的条目，配合 PR 编号深入提交历史；
2. 选择版本基线：优先以次版本（2.9.0 这类）为参照系读功能条目，小版本（2.9.6）条目则侧重修复清单，用于评估补丁升级风险；
3. 核对版本一致性：将 cli/lib/version.txt 与文档首条 ### 2.9.6 / 2026.08.27 对照，可确认当前工作副本对应文档中的哪一个版本；
4. 理解发布产物：结合 release_doc_template.md 中的资产数量校验（46 个 GitHub 资产 / 48 个分发端 zip）与 release-latest.txt 回滚机制，可以完整理解“下载到的二进制”与“文档中的条目”之间的对应关系。

Releases.md 因此不只是一份历史记录：它是 Deno 版本语义（feat/fix/perf + PR 编号）、仓库模块划分（scope 与目录映射）和发布工程（tools/release 流水线）三者交叉的索引，是排查回归、评估升级与追踪 Deno 技术路线时最可靠的入口。