Electron 版本控制

🌐 Electron Versioning

对我们的版本控制政策和实现的详细解读。

从版本 2.0.0 起，Electron 遵循 SemVer 规范。以下命令将安装 Electron 的最新稳定版本：

🌐 As of version 2.0.0, Electron follows the SemVer spec. The following command will install the most recent stable build of Electron:

npm

npm install --save-dev electron

Yarn

yarn add --dev electron

要更新现有项目以使用最新的稳定版本：

🌐 To update an existing project to use the latest stable version:

npm

npm install --save-dev electron@latest

Yarn

yarn add --dev electron@latest

SemVer

下面是一个表，将更改类型显式映射到其相应的 SemVer 类别（例如，主要、次要、补丁）。

🌐 Below is a table explicitly mapping types of changes to their corresponding category of SemVer (e.g. Major, Minor, Patch).

主要版本增量	次要版本增量	补丁版本增量
Electron 破坏性 API 变化	Electron 非破坏性 API 变化	Electron 错误修复
Node.js 主要版本更新	Node.js 次要版本更新	Node.js 补丁版本更新
Chromium 版本更新		修复相关的 Chromium 补丁

欲了解更多信息，请参阅 语义化版本控制 2.0.0 规范。

🌐 For more information, see the Semantic Versioning 2.0.0 spec.

请注意，大多数 Chromium 更新会被视为重大更新。可以回溯移植的修复通常会作为补丁进行挑选。

🌐 Note that most Chromium updates will be considered breaking. Fixes that can be backported will likely be cherry-picked as patches.

稳定分支

🌐 Stabilization branches

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

🌐 Stabilization branches are branches that run parallel to main, taking in only cherry-picked commits that are related to security or stability. These branches are never merged back to main.

自从 Electron 8 起，稳定分支始终是主版本线，并按照以下模板命名 $MAJOR-x-y，例如 8-x-y。（在此之前，我们使用的是次要版本线，并将其命名为 $MAJOR-$MINOR-x，例如 2-0-x。）

🌐 Since Electron 8, stabilization branches are always major version lines, and named against the following template $MAJOR-x-y e.g. 8-x-y. (Prior to that, we used minor version lines and named them as $MAJOR-$MINOR-x e.g. 2-0-x.)

我们允许多个稳定分支同时存在，每个受支持的版本各一个。

🌐 We allow for multiple stabilization branches to exist simultaneously, one for each supported version.

tip

有关支持哪些版本的更多详细信息，请参阅我们的 Electron 版本 文档。

老版本将不再被 Electron 项目支持。

🌐 Older lines will not be supported by the Electron project.

发布周期

🌐 Release cycle

Electron 遵循 8 周的常规发布周期，关键里程碑对应于 Chromium 发布周期中的相应日期。

🌐 Electron follows an 8-week regular release cycle where key milestones correspond to matching dates in the Chromium release cycle.

示例

🌐 Example

当 Electron 41 发布稳定版本时，Electron 42 的发布分支将从 main 分支出来。它的第一个 alpha 版本包含在 main 上的所有更改：

🌐 When Electron 41 hits its stable release, the release line for Electron 42 is branched off of main. Its first alpha release is created with all the changes contained on main:

一个错误修复进入了 main，可以回移到发布分支。补丁已应用，并在下一个 v42.0.0-alpha.2 版本中发布。

🌐 A bug fix comes into main that can be backported to the release branch. The patch is applied, and it is published in the next v42.0.0-alpha.2 release.

驱动 Electron 42 的 Chromium 版本进入了 Chrome 的测试版渠道。alpha 分支被提升到 beta。

🌐 The version of Chromium that powers Electron 42 hits Chrome's beta channel. The alpha line is promoted to beta.

Beta 版本每周发布，直到 Electron 42 升级为稳定版，然后相同的周期从 43-x-y 开始。之后，一个零日漏洞被披露，并在 main 上应用了修复。我们将修复回移到 42-x-y 系列并发布 42.0.1。

🌐 Beta releases continue weekly until Electron 42 is promoted to stable and the same cycle starts again with 43-x-y. Later, a zero-day exploit is revealed and a fix is applied to main. We backport the fix to the 42-x-y line and release 42.0.1.

向后移植请求进程

🌐 Backport request process

所有受支持的发布分支都将接受外部拉取请求，以回移以前合并到 main 的修复，尽管对于一些较旧的受支持分支，这可能需要逐案处理。所有关于发布分支回移的有争议决定将由 发布工作组 在每周会议中作为议程项目进行解决，会议将在提出回移拉取请求的那周举行。

🌐 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.

功能标志

🌐 Feature flags

功能标记在 Chromium 中是常见的做法，并且在网页开发生态系统中已被广泛认可。在 Electron 的上下文中，功能标记或软分支必须具备以下特性：

🌐 Feature flags are a common practice in Chromium, and are well-established in the web-development ecosystem. In the context of Electron, a feature flag or soft branch must have the following properties:

• 它可以在运行时或构建时启用/禁用；我们不支持基于请求范围的功能开关概念
• 它完全将新旧代码路径分开；为了支持新功能而重构旧代码会 违反 功能开关协议
• 功能发布后，功能标志最终会被删除

语义提交

🌐 Semantic commits

所有拉取请求必须遵循 Conventional Commits 规范，可归纳如下：

🌐 All pull requests must adhere to the Conventional Commits spec, which can be summarized as follows:

• 会导致 SemVer 大版本 提升的提交，其正文必须以 BREAKING CHANGE: 开头。
• 会导致 SemVer 次要 版本升级的提交必须以 feat: 开头。
• 会导致 SemVer 修补版本 更新的提交必须以 fix: 开头。

electron/electron 仓库也强制使用 squash 合并，因此你只需要确保你的拉取请求有正确的标题前缀。

🌐 The electron/electron repository also enforces squash merging, so you only need to make sure that your pull request has the correct title prefix.

版本化的 main 分支

🌐 Versioned main branch

• main 分支总是对应于当前预发行版本线之上的主要版本。
• main 的不稳定夜间版本通过 npm 上的 electron-nightly 包发布。
• 发布分支从不合并回 main。
• 所有 package.json 值都固定为 0.0.0-development。

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

🌐 Historical versioning (Electron 1.X)

Electron 版本 < 2.0 并不符合 SemVer 规范：主版本对应终端用户 API 的变更，次版本对应 Chromium 的主要版本发布，修订版本对应新功能和漏洞修复。虽然这种方式便于开发者合并功能，但对于面向客户的应用开发者而言，这会带来问题。像 Slack、Teams、VS Code 和 GitHub Desktop 这样的重要应用的 QA 测试周期可能很长，而稳定性是非常重要的结果。在尝试吸收漏洞修复的同时采用新功能存在很高的风险。

🌐 Electron versions < 2.0 did not conform to the SemVer spec: major versions corresponded to end-user API changes, minor versions corresponded to Chromium major releases, and patch versions corresponded to new features and bug fixes. While convenient for developers merging features, it creates problems for developers of client-facing applications. The QA testing cycles of major apps like Slack, Teams, VS Code, and GitHub Desktop can be lengthy and stability is a highly desired outcome. There is a high risk in adopting new features while trying to absorb bug fixes.

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

🌐 Here is an example of the 1.x strategy:

使用 1.8.1 开发的应用无法在不引入 1.8.2 功能的情况下获取 1.8.3 的错误修复，除非通过回移补丁并维护一个新的版本路线。

🌐 An app developed with 1.8.1 cannot take the 1.8.3 bug fix without either absorbing the 1.8.2 feature, or by backporting the fix and maintaining a new release line.