跳至主要内容

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.1Security 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 功能,或者通过反向移植修复并维护新的发布版本线。