跳转到主内容

Electron 版本管理

详细查看我们的版本控制策略和实现。

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

npm install --save-dev electron

现有项目更新到最新的稳定版本:

npm install --save-dev electron@latest

SemVer​

下面是一个表格，明确地将变化的类型映射到它们对应的 SemVer 类别 (例如Major，Minor，Patch)。

Major 版本增量Minor 版本增量Patch 版本增量
Electron 突破性 API 变更Electron 无突破性 API 变更Electron bug 修复
Node.js 重大版本更新Node.js 次要版本更新Node.js patch 版本更新
Chromium 版本更新fix-related Chromium patches

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

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

稳定分支​

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

自 Electron 8 以来，稳定分支始终为 marjar 版本，并且根据以下模板 $MAJOR-x-y 例如： 8-x-y。 (Prior to that, we used minor version lines and named them as $MAJOR-$MINOR-x e.g. 2-0-x.)

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

[!TIP] For more details on which versions are supported, see our Electron Releases doc.

Older lines will not be supported by the Electron project.

Release cycle​

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

示例​

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:

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.

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

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​

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 always corresponds to the major version above the current pre-release line.
  • Unstable nightly releases of main are released under the electron-nightly package on npm.
  • Release branches are never merged back to main.
  • All package.json values are fixed at 0.0.0-development.

历史版本（Electron 1.X）​

_小于 2.0 _ 的 Electron 版本编号并不遵循 SemVer 规范: major 版本对应最终用户 API 的变更, minor 版本更新对应 Chromium 的主版本更新, patch 版本更新会带来新功能和 bug 修复。 虽然方便开发人员合并功能，但却为面向客户端应用程序的开发人员带来了麻烦。 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. 尝试吸收错误修复时，采用新功能的风险很高。

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

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