跳转到主内容

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)。

Major 版本增量Minor 版本增量Patch 版本增量
Electron 突破性 API 变更Electron 无突破性 API 变更Electron bug 修复
Node.js 重大版本更新Node.js 次要版本更新Node.js patch 版本更新
Chromium 版本更新修复相关的 chromium 补丁

更多信息请参阅“Semantic Versioning 2.0.0”。

请注意，大多数 Chromium 更新都将被认为是破坏性的。 可以向后移植的修复可能会被挑选为补丁。

稳定分支​

稳定分支是与main分支平行运行的分支，只接受与安全性或稳定性相关的遴选提交。 这些分支从不合并回main分支。

稳定分支

自 Electron 8 以来，稳定分支始终为 marjar 版本，并且根据以下模板 $MAJOR-x-y 例如： 8-x-y。 在此之前，我们使用 minor 版本行，并将它们命名为 $MAJOR-$MINOR-x 例如： 2-0-x.

我们允许同时存在多个稳定分支，每个分支对应一个支持的版本。 要了解支持版本的更多详细信息，请参阅我们的 Electron Releases 文档。

多个稳定分支

Electron项目不会支持旧的版本，但其他团体可以自行接管并回溯稳定性和安全性修复。 我们不鼓励这样做，但是认识到它使得许多应用程序开发人员的生活更轻松。

测试版发布和 bug 修复​

开发人员想知道哪个版本可以 安全 使用。 即使是简单的功能也会使应用程序变得复杂。 同时，锁定到一个固定的版本是很危险的，因为你忽略了自你的版本以来可能出现的安全补丁和错误修复。 我们的目标是在 package.json 中允许以下标准的 semver 范围:

  • 使用 ~ 2.0. 0 只接受您的 2.0.0 版本的稳定性或安全性相关的修复程序。
  • 使用 ^ 2.0. 0 可允许不破坏性的 _ 合理稳定 _ 功能以及安全性和 bug 修复。

第二点重要的是使用 ^ 的应用程序仍然能够期望合理的稳定性水平。 为了达到这个目的，SemVer允许使用一个 pre-release 标识 来表示一个特定的版本还不够 安全 或 稳定。

无论你选择什么，你将定期不得不在 package.json 中打破版本，因为突破性变更是 Chromium 的一个常态。

过程如下:

  1. 所有新的主要和次要版本的发布线都以beta开始， 使用SemVer预发布标签beta.N进行标示，例如： 2.0.0-beta.1。 在第一个beta版本之后，后续的beta版本发布必须满足以下所有条件：
    1. 更改是落后的 API 兼容 (允许废弃)
    2. 实现我们稳定的时间表的危险必须是低的。
  2. 如果允许更改需要在释放测试版之后进行，则使用并增加预放标签，例如2.0.0-beta.2。
  3. 如果特定的beta版本_通常被认为_是稳定的，那么它将作为稳定版本被重新发布，只改变版本信息。例如.0。 例如 2.0.0-beta.1. 在第一个稳定之后，所有的变化都必须落后兼容的 bug 或安全修复。
  4. 如果未来错误修复或安全补丁一旦发布稳定，它们将被应用，并且 补丁 版本被增量 ，例如 2.0.1。

特别地，上述步骤意味着：

  1. 在测试周期的第 3 周前允许非破坏性的 API 更改，即使这些变化有可能造成适度的副影响。
  2. 在beta周期的大部分时间内，可以接受带有功能标志的更改，只要这些更改不会影响现有的代码路径。 用户可以在他们的应用程序中显式启用这些标志。
  3. 在Beta周期的第三周之后，没有非常充分的理由的情况下，不应该引入任何类型的新功能。👎

对于每个主要和次要的颠覆，你都应该像以下示例一样进行操作：

2.0.0-beta.1
2.0.0-beta.2
2.0.0-beta.3
2.0.0
2.0.1
2.0.2

图片中的生命周期示例:

  • 创建一个新的 release 分支，其中包含最新的一组功能。 它会被发布为 2.0.0-beta.1。 新发行版
  • A bug fix comes into master that can be backported to the release branch. The patch is applied, and a new beta is published as 2.0.0-beta.2. 修复的 bug 移植至测试版
  • 测试版被认为是 _ 一般稳定 _ 的, 它在 2.0.0 下作为非 beta 版本再次被发布。 测试版至稳定版
  • 之后有个 0day 漏洞被发现，然后对 master 采取了修复措施。 We backport the fix to the 2-0-x line and release 2.0.1. 安全��移植

几个不同的 SemVer 范围将如何接收新版本的示例:

Semvers 和发行版

Backport request process​

All supported release lines will accept external pull requests to backport fixes previously merged to main, though this may be on a case-by-case basis for some older supported lines. All contested decisions around release line backports will be resolved by the Releases Working Group as an agenda item at their weekly meeting the week the backport PR is raised.

功能标志​

功能标志是 Chromium 的一种常见的做法, 在网络开发生态系统中得到了很好的确立。 在 Electron 环境中, 功能标志或 ** 软分支 ** 必须具有以下属性:

  • 是在运行时或生成时启用/禁用的。我们不支持请求作用域功能标志的概念
  • 它完全细分新的和旧的代码路径; 重构旧代码以允许新功能 _ 违反 _ 功能标志内容
  • 在合并功能后, 功能标志最终将被删除

语义化提交​

所有合并请求必须遵循 Conventional Commits 规范提交，可以总结如下：

  • 会导致 SemVer major 版本改变的提交必须以BREAKING CHANGE:开头。
  • 会导致 SemVer minor 版本改变的提交必须以 feat: 开头。
  • 会导致 SemVer ** patch ** 版本改变的提交必须以 fix: 开头。

electron/electron仓库还强制使用合并压缩（squash merging），因此只需要确保你的合并请求具有正确的标题前缀即可。

Versioned main branch​

  • The main branch will always contain the next major version X.0.0-nightly.DATE in its package.json.
  • Release branches are never merged back to main.
  • 发布分支 在 其package.json 中包含正确的版本.
  • As soon as a release branch is cut for a major, main must be bumped to the next major (i.e. main is always versioned as the next theoretical release branch).

历史版本（Electron 1.X）​

_小于 2.0 _ 的 Electron 版本编号并不遵循 SemVer 规范: major 版本对应最终用户 API 的变更, minor 版本更新对应 Chromium 的主版本更新, patch 版本更新会带来新功能和 bug 修复。 虽然方便开发人员合并功能，但却为面向客户端应用程序的开发人员带来了麻烦。 像Slack、Teams、Skype、VS Code和GitHub Desktop等主要应用程序的QA测试周期可能会很长，稳定性是一个非常理想的结果。 尝试吸收错误修复时，采用新功能的风险很高。

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

1.x 版本

使用 1.8.1开发的应用程序无法吸收 1.8.2 的功能，或者通过反向移植修复和维护新的发行版，无法采用 1.8.3错误修复。