跳至主要内容

Electron 版本控制

详细了解我们的版本控制策略和实现。

从版本 2.0.0 开始，Electron 遵循 SemVer 规范。以下命令将安装 Electron 最新的稳定版本：

npm install --save-dev electron

更新现有项目以使用最新的稳定版本：

npm install --save-dev electron@latest

版本控制方案​

与下面概述的 1.x 策略相比，有几项重大变化。每项变化旨在满足开发者/维护者和应用开发者的需求和优先事项。

  1. 严格遵循 SemVer 规范
  2. 引入符合 semver 的 -beta 标签
  3. 引入 conventional commit messages
  4. 定义明确的稳定分支
  5. main 分支没有版本信息；只有稳定分支包含版本信息

我们将详细介绍 git 分支的工作原理、npm 标签的工作原理、开发者应该期望看到的内容以及如何回移植更改。

SemVer​

下表明确列出了更改类型及其对应的 SemVer 类别（例如，主要、次要、补丁）。

主版本递增次版本递增补丁版本递增
Electron 重大 API 变更Electron 非重大 API 变更Electron 错误修复
Node.js 主版本更新Node.js 次版本更新Node.js 补丁版本更新
Chromium 版本更新与修复相关的 Chromium 补丁

更多信息，请参见 Semantic Versioning 2.0.0 规范。

请注意，大多数 Chromium 更新将被视为重大变更。可回移植的修复将可能作为补丁精选并应用。

稳定分支​

稳定分支是与 main 并行运行的分支，只接受与安全或稳定性相关的精选的提交。这些分支永远不会合并回 main。

Stabilization Branches

从 Electron 8 开始，稳定分支始终是**主**版本线，并按以下模板命名 $MAJOR-x-y，例如 8-x-y。在此之前，我们使用**次要**版本线，并将其命名为 $MAJOR-$MINOR-x，例如 2-0-x。

我们允许同时存在多个稳定分支，每个支持的版本对应一个。有关支持哪些版本的更多详细信息，请参阅我们的 Electron 发行版本 文档。

Multiple Stability Branches

较旧的版本线将不再由 Electron 项目支持，但其他团体可以自行接管并回移植稳定性和安全修复。我们不鼓励这样做，但承认这会使许多应用开发者的工作更轻松。

Beta 版本和错误修复​

开发者想知道哪些版本是*安全*使用的。即使看似无害的功能也可能在复杂的应用程序中引入回归。同时，锁定到固定版本是危险的，因为您会忽略自您的版本发布以来可能出现的安全补丁和错误修复。我们的目标是允许在 package.json 中使用以下标准 semver 范围：

  • 使用 ~2.0.0 只接受与您的 2.0.0 版本相关的稳定性或安全修复。
  • 使用 ^2.0.0 接受非重大的*合理稳定*的功能工作以及安全和错误修复。

关于第二点重要的是，使用 ^ 的应用仍应能够期望合理的稳定性水平。为了实现这一点，SemVer 允许使用*预发布标识符*来表明特定版本尚不*安全*或不*稳定*。

无论您选择哪种方式，您都需要定期提高 package.json 中的版本，因为重大变更在 Chromium 中是常有的事。

流程如下：

  1. 所有新的主要和次要发行版本线都始于 beta 系列，由 SemVer 预发布标签 beta.N 表示，例如 2.0.0-beta.1。在第一个 beta 版本之后，后续 beta 版本必须满足以下所有条件：
    1. 更改向后兼容 API（允许弃用）
    2. 达到我们稳定性时间线的风险必须很低。
  2. 如果在版本处于 beta 阶段时需要进行允许的更改，则应用更改并递增预发布标签，例如 2.0.0-beta.2。
  3. 如果某个 beta 版本被*普遍认为*稳定，它将作为稳定版本重新发布，只更改版本信息。例如 2.0.0。在第一个稳定版本发布后，所有更改必须是向后兼容的错误或安全修复。
  4. 如果在版本稳定后需要进行未来的错误修复或安全补丁，则应用它们并递增*补丁*版本，例如 2.0.1。

具体而言，上述内容意味着：

  1. 在 beta 周期第 3 周之前允许非重大 API 更改是可以的，即使这些更改有可能引起中等程度的副作用。
  2. 在 beta 周期的绝大多数时间点允许带有功能标志的更改（它们不会改变现有代码路径）是可以的。用户可以在其应用中明确启用这些标志。
  3. 在 beta 周期第 3 周之后，在没有非常好的理由的情况下允许任何类型的功能是 👎。

对于每个主要和次要版本升级，您应该会看到如下情况：

2.0.0-beta.1
2.0.0-beta.2
2.0.0-beta.3
2.0.0
2.0.1
2.0.2

图示示例生命周期

  • 创建一个新的发布分支，包含最新的功能集。它发布为 2.0.0-beta.1。新发布分支
  • 一个错误修复进入 master 分支，可以回移植到发布分支。应用该补丁，并发布一个新的 beta 版本，即 2.0.0-beta.2。Bug 修复回移植到 Beta
  • 该 beta 版本被认为*普遍稳定*，并以非 beta 形式在 2.0.0 下再次发布。Beta 到稳定版
  • 后来，发现了一个零日漏洞，并在 master 分支中应用了修复。我们将修复回移植到 2-0-x 版本线并发布 2.0.1。安全回移植

关于不同 SemVer 范围如何获取新版本的一些示例

Semvers and Releases

回移植请求流程​

所有受支持的发布版本线都将接受将先前合并到 main 分支的修复回移植的外部拉取请求，尽管对于一些较旧的受支持版本线，这可能是根据具体情况处理的。所有关于发布版本线回移植的有争议的决定将由 版本发布工作组 在提交回移植 PR 的那一周的每周会议上作为议程项目解决。

功能标志​

功能标志在 Chromium 中是常见做法，并且在 Web 开发生态系统中已经确立。在 Electron 的上下文中，功能标志或**软分支**必须具有以下属性：

  • 它可以在运行时或构建时启用/禁用；我们不支持请求范围的功能标志概念
  • 它完全隔离了新旧代码路径；重构旧代码以支持新功能*违反*了功能标志约定
  • 功能标志在功能发布后最终会被移除

语义化提交​

所有拉取请求必须遵守 Conventional Commits 规范，该规范可概括如下：

  • 会导致 SemVer **主要**版本升级的提交，其正文必须以 BREAKING CHANGE: 开头。
  • 会导致 SemVer **次要**版本升级的提交，必须以 feat: 开头。
  • 会导致 SemVer **补丁**版本升级的提交，必须以 fix: 开头。

electron/electron 仓库还强制执行 squash 合并，因此您只需要确保您的拉取请求标题具有正确的前缀。

版本化的 main 分支​

  • main 分支在其 package.json 中始终包含下一个主要版本 X.0.0-nightly.DATE。
  • 发布分支永远不会合并回 main。
  • 发布分支*确实*在其 package.json 中包含正确的版本。
  • 一旦为主要版本剪切了发布分支，main 分支必须升级到下一个主要版本（即 main 始终版本化为下一个理论上的发布分支）。

历史版本控制 (Electron 1.X)​

Electron 版本 *< 2.0* 不符合 SemVer 规范：主要版本对应于终端用户 API 更改，次要版本对应于 Chromium 主要发布版本，补丁版本对应于新功能和错误修复。虽然这对于合并功能的开发者来说很方便，但对面向客户端应用程序的开发者来说会带来问题。像 Slack、Teams、Skype、VS Code 和 GitHub Desktop 这样主要应用的 QA 测试周期可能很长，稳定性是高度期望的结果。在尝试吸收错误修复的同时采用新功能存在高风险。

以下是 1.x 策略的一个示例：

1.x Versioning

用 1.8.1 开发的应用无法在不吸收 1.8.2 功能的情况下获得 1.8.3 的错误修复，除非回移植该修复并维护一个新的发布版本线。