跳转到主要内容

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 补丁

有关更多信息，请参阅 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 允许使用预发布标识符来表示特定版本尚未安全或稳定。

无论您如何选择，随着 Chromium 带来的破坏性更改，您将需要定期更新 package.json 中的版本。

流程如下：

  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
  • 一个可以反向移植到发布分支的 bug 修复进入了 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 的上下文中，功能标志或软分支必须具备以下属性：

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

语义化提交​

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

  • 将导致 SemVer主版本号增加的提交必须在其正文开头包含 BREAKING CHANGE:。
  • 将导致 SemVer次版本号增加的提交必须以 feat: 开头。
  • 将导致 SemVer修订版本号增加的提交必须以 fix: 开头。

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

带版本的 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、VS Code 和 GitHub Desktop 这样的主要应用程序的 QA 测试周期可能很长，并且高度重视稳定性。在尝试吸收错误修复的同时采纳新功能存在很大风险。

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

1.x Versioning

使用 1.8.1 开发的应用程序，如果不想吸收 1.8.2 的功能，则无法获取 1.8.3 的错误修复，或者需要反向移植修复程序并维护一个新的发布分支。