进阶 electronjs.org 2026-10-07 23:51:43 · 6 阅读
第22章 Electron 版本管理与发布策略详解
Electron 版本管理
详细介绍我们的版本策略及其实现方式。
从 2.0.0 版本开始，Electron 遵循 SemVer 规范。以下命令可安装最新稳定版 Electron：
npmYarnnpm install --save-dev electron
yarn add --dev electron
如需将现有项目更新到最新稳定版： npmYarnnpm install --save-dev electron@latest
yarn add --dev electron@latest
SemVer 下图是一个表格，它将变更类型映射到对应的 SemVer 类别（如 Major、Minor、Patch）。 Major 版本升级：Electron 破坏性 API 变更 Minor 版本升级：Electron 非破坏性 API 变更、Node.js major 版本更新 Patch 版本升级：Electron bug 修复、Node.js minor/patch 版本更新、Chromium 版本更新、与修复相关的 Chromium 补丁 欲知详情，请参阅 Semantic Versioning 2.0.0 规范。 注意，大多数 Chromium 更新被视为破坏性变更。可向下兼容的修复通常会以 patch 形式 cherry-pick 进去。 稳定分支 稳定分支是并行于 main 分支运行的分支，仅接受与安全性或稳定性相关的 cherry-pick 提交。这些分支永远不会合并回 main。 从 Electron 8 开始，稳定分支始终是 major 版本线，并遵循 $MAJOR-x-y 命名模板，例如 8-x-y。（在此之前，我们使用 minor 版本线，命名为 $MAJOR-$MINOR-x，例如 2-0-x。） 我们允许同时存在多个稳定分支，每个受支持的版本对应一个。 提示：关于哪些版本受支持的详细信息，请参阅我们的 Electron Releases 文档。 较旧的版本线将不再得到 Electron 项目支持。 发布周期 Electron 遵循 8 周的常规发布周期，其关键里程碑与 Chromium 发布周期中的对应日期保持一致。 示例 当 Electron 41 发布稳定版时，Electron 42 的发布分支将从 main 分支切出。 其首个 alpha 版本将包含 main 分支上的所有变更： 一个可回移植到发布分支的 bug 修复被合并入 main。该补丁被应用，并在下一个 v42.0.0-alpha.2 版本中发布。 驱动 Electron 42 的 Chromium 版本进入 Chrome 的 beta 渠道。Alpha 版本线随后升级为 beta。 Beta 版本每周持续发布，直到 Electron 42 升级为稳定版，然后以 43-x-y 开启新的循环。稍后，一个 0-day 漏洞被发现，修复被应用于 main 分支。我们将该修复回移植到 42-x-y 版本线并发布 42.0.1。 回移植申请流程 所有受支持的发布分支均接受外部 pull request，用于回移植先前已合并到 main 的修复，但对于某些较旧的受支持版本线，这可能需逐一评估。所有关于发布分支回移植的争议性决策，将由 Releases Working Group 在 backport PR 提交那一周的周会上作为议程项解决。 特性开关 特性开关是 Chromium 中的常见做法，在 Web 开发生态中已相当成熟。在 Electron 语境下，特性开关或软分支必须满足以下属性： 它在运行时或构建时启用/禁用；我们不支持请求作用域的特性开关概念 它完全隔离新旧代码路径；重构旧代码以支持新功能会违反特性开关契约 特性开关最终会在功能发布后移除 语义化提交 所有 pull request 必须遵循 Conventional Commits 规范，总结如下： 导致 SemVer major 升级的提交，其正文必须以 BREAKING CHANGE: 开头。 导致 SemVer minor 升级的提交必须以 feat: 开头。 导致 SemVer patch 升级的提交必须以 fix: 开头。 electron/electron 仓库还强制 squash 合并，因此你只需确保 pull request 具有正确的标题前缀即可。 版本化的 main 分支 main 分支始终对应于当前预发布版本线的上一 major 版本。 main 的不稳定夜间版本以 electron-nightly 包的形式发布在 npm 上。 发布分支永远不会合并回 main。 所有 package.json 值固定为 0.0.0-development。 历史版本管理（Electron 1.X） 低于 2.0 的 Electron 版本不符合 SemVer 规范：major 版本对应终端用户 API 变更，minor 版本对应 Chromium major 发布，patch 版本对应新功能和 bug 修复。这对合并功能的开发者很方便，但给面向客户端应用的开发者带来了问题。Slack、Teams、VS Code 和 GitHub Desktop 等大型应用的 QA 测试周期较长，且稳定性是高度期望的结果。在吸收 bug 修复的同时采用新功能存在高风险。 以下是 1.x 策略的一个示例： 基于 1.8.1 开发的应用程序若要获取 1.8.3 的 bug 修复，必须要么吸收 1.8.2 的功能，要么通过回移植修复并维护一个新的发布线来实现。
yarn add --dev electron
如需将现有项目更新到最新稳定版： npmYarnnpm install --save-dev electron@latest
yarn add --dev electron@latest
SemVer 下图是一个表格，它将变更类型映射到对应的 SemVer 类别（如 Major、Minor、Patch）。 Major 版本升级：Electron 破坏性 API 变更 Minor 版本升级：Electron 非破坏性 API 变更、Node.js major 版本更新 Patch 版本升级：Electron bug 修复、Node.js minor/patch 版本更新、Chromium 版本更新、与修复相关的 Chromium 补丁 欲知详情，请参阅 Semantic Versioning 2.0.0 规范。 注意，大多数 Chromium 更新被视为破坏性变更。可向下兼容的修复通常会以 patch 形式 cherry-pick 进去。 稳定分支 稳定分支是并行于 main 分支运行的分支，仅接受与安全性或稳定性相关的 cherry-pick 提交。这些分支永远不会合并回 main。 从 Electron 8 开始，稳定分支始终是 major 版本线，并遵循 $MAJOR-x-y 命名模板，例如 8-x-y。（在此之前，我们使用 minor 版本线，命名为 $MAJOR-$MINOR-x，例如 2-0-x。） 我们允许同时存在多个稳定分支，每个受支持的版本对应一个。 提示：关于哪些版本受支持的详细信息，请参阅我们的 Electron Releases 文档。 较旧的版本线将不再得到 Electron 项目支持。 发布周期 Electron 遵循 8 周的常规发布周期，其关键里程碑与 Chromium 发布周期中的对应日期保持一致。 示例 当 Electron 41 发布稳定版时，Electron 42 的发布分支将从 main 分支切出。 其首个 alpha 版本将包含 main 分支上的所有变更： 一个可回移植到发布分支的 bug 修复被合并入 main。该补丁被应用，并在下一个 v42.0.0-alpha.2 版本中发布。 驱动 Electron 42 的 Chromium 版本进入 Chrome 的 beta 渠道。Alpha 版本线随后升级为 beta。 Beta 版本每周持续发布，直到 Electron 42 升级为稳定版，然后以 43-x-y 开启新的循环。稍后，一个 0-day 漏洞被发现，修复被应用于 main 分支。我们将该修复回移植到 42-x-y 版本线并发布 42.0.1。 回移植申请流程 所有受支持的发布分支均接受外部 pull request，用于回移植先前已合并到 main 的修复，但对于某些较旧的受支持版本线，这可能需逐一评估。所有关于发布分支回移植的争议性决策，将由 Releases Working Group 在 backport PR 提交那一周的周会上作为议程项解决。 特性开关 特性开关是 Chromium 中的常见做法，在 Web 开发生态中已相当成熟。在 Electron 语境下，特性开关或软分支必须满足以下属性： 它在运行时或构建时启用/禁用；我们不支持请求作用域的特性开关概念 它完全隔离新旧代码路径；重构旧代码以支持新功能会违反特性开关契约 特性开关最终会在功能发布后移除 语义化提交 所有 pull request 必须遵循 Conventional Commits 规范，总结如下： 导致 SemVer major 升级的提交，其正文必须以 BREAKING CHANGE: 开头。 导致 SemVer minor 升级的提交必须以 feat: 开头。 导致 SemVer patch 升级的提交必须以 fix: 开头。 electron/electron 仓库还强制 squash 合并，因此你只需确保 pull request 具有正确的标题前缀即可。 版本化的 main 分支 main 分支始终对应于当前预发布版本线的上一 major 版本。 main 的不稳定夜间版本以 electron-nightly 包的形式发布在 npm 上。 发布分支永远不会合并回 main。 所有 package.json 值固定为 0.0.0-development。 历史版本管理（Electron 1.X） 低于 2.0 的 Electron 版本不符合 SemVer 规范：major 版本对应终端用户 API 变更，minor 版本对应 Chromium major 发布，patch 版本对应新功能和 bug 修复。这对合并功能的开发者很方便，但给面向客户端应用的开发者带来了问题。Slack、Teams、VS Code 和 GitHub Desktop 等大型应用的 QA 测试周期较长，且稳定性是高度期望的结果。在吸收 bug 修复的同时采用新功能存在高风险。 以下是 1.x 策略的一个示例： 基于 1.8.1 开发的应用程序若要获取 1.8.3 的 bug 修复，必须要么吸收 1.8.2 的功能，要么通过回移植修复并维护一个新的发布线来实现。
