跳至主要内容

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 类别（例如，主版本、次版本、修订版本）。

主版本增量次版本增量修订版本增量
Electron 中断 API 更改Electron 非中断 API 更改Electron 错误修复
Node.js 主版本更新Node.js 次版本更新Node.js 修订版本更新
Chromium 版本更新与修复相关的 Chromium 修补程序

有关更多信息，请参阅 语义版本控制 2.0.0 规范。

请注意，大多数 Chromium 更新将被视为中断性更改。可以回溯的修复程序很可能会作为修补程序进行 cherry-pick。

稳定化分支​

稳定化分支是与 main 平行运行的分支，仅接收与安全或稳定性相关的 cherry-pick 提交。这些分支永远不会合并回 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。 错误修复回溯到 Beta 版
  • beta 版被认为是普遍稳定的，它再次发布为非 beta 版，名为 2.0.0。 Beta 版到稳定版
  • 之后，发现了一个零日漏洞，并将修复程序应用到 master。我们将修复程序回溯到 2-0-x 版本线，并发布 2.0.1。 安全回溯

一些关于各种 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的功能，或者通过将修复程序移植回旧版本并维护新的发布分支。