跳至主要内容

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. 引入 约定式提交消息
  4. 定义良好的稳定化分支
  5. main 分支没有版本信息；只有稳定化分支包含版本信息

我们将详细介绍 git 分支如何工作、npm 标签如何工作、开发者应该看到什么，以及如何反向移植变更。

SemVer​

下表明确地将变更类型映射到其对应的 SemVer 类别（例如，Major、Minor、Patch）。

主版本增量次版本增量补丁版本增量
Electron 破坏性 API 变更Electron 非破坏性 API 变更Electron 错误修复
Node.js 主版本更新Node.js 次版本更新Node.js 补丁版本更新
Chromium 版本更新与修复相关的 chromium 补丁

有关更多信息，请参阅 语义化版本 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 发布。 New Release Branch
  • 一个错误修复进入了 master 分支，可以反向移植到发布分支。 应用了补丁，并以 2.0.0-beta.2 发布了一个新的 beta 版本。 Bugfix Backport to Beta
  • 该 beta 版本被认为是通常稳定的，并且再次以非 beta 版本的形式在 2.0.0 下发布。 Beta to Stable
  • 之后，发现了一个零日漏洞，并且将一个修复应用于 master 分支。 我们将修复反向移植到 2-0-x 版本线并发布 2.0.1。 Security Backports

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

Semvers and Releases

反向移植请求流程​

所有受支持的发布版本线都将接受外部拉取请求，以反向移植之前合并到 main 的修复，尽管对于某些较旧的受支持版本线，这可能是具体情况而定的。 有关发布版本线反向移植的所有有争议的决定将由 发布工作组 在其每周会议上作为议程项目来解决，会议时间为提出反向移植 PR 的那周。

功能标志​

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

  • 它在运行时或构建时启用/禁用； 我们不支持请求范围的功能标志的概念
  • 它完全分割了新的和旧的代码路径； 重构旧代码以支持新功能违反了功能标志合同
  • 功能标志在功能发布后最终会被删除

语义化提交​

所有拉取请求都必须遵守 约定式提交 规范，该规范可以总结如下

  • 会导致 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.3 错误修复，而无需吸收 1.8.2 功能，或者通过反向移植修复并维护新的发布版本线。