跳转到主要内容

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 更新将被视为破坏性更改。可以回溯的修复很可能会被选择性地作为补丁。

稳定分支​

稳定分支是与 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。应用补丁，并发布一个新的 beta 版本，即 2.0.0-beta.2。 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 分支将始终包含下一个主要版本 X.0.0-nightly.DATE 在其 package.json 中。
  • 发布分支永远不会合并回 main。
  • 发布分支确实在其 package.json 中包含正确的版本。
  • 一旦为主要版本切割发布分支，main 必须升级到下一个主要版本（即 main 始终被版本化为下一个理论发布分支）。

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

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

以下是 1.x 策略的示例

1.x Versioning

使用 1.8.1 开发的应用程序无法获取 1.8.3 错误修复，而无需吸收 1.8.2 功能，或通过回溯修复并维护新的发布行。