Electron 版本控制
详细了解我们的版本控制策略和实施。
从 2.0.0 版本开始,Electron 遵循 SemVer 规范。以下命令将安装 Electron 最新的稳定版本
- npm
- Yarn
npm install --save-dev electron
yarn add --dev electron
要更新现有项目以使用最新的稳定版本
- npm
- Yarn
npm install --save-dev electron@latest
yarn add --dev electron@latest
版本控制方案
我们 1.x 策略有几个重大变化,如下所述。每个更改旨在满足开发者/维护者和应用开发者的需求和优先级。
我们将详细介绍 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
。
自 Electron 8 以来,稳定分支始终是主版本线,并根据以下模板 $MAJOR-x-y
命名,例如 8-x-y
。在此之前,我们使用次版本线,并将其命名为 $MAJOR-$MINOR-x
,例如 2-0-x
。
我们允许同时存在多个稳定分支,每个受支持的版本一个。有关支持哪些版本的更多详细信息,请参阅我们的 Electron 发行版本 文档。
较旧的版本线将不受 Electron 项目的支持,但其他组可以自行承担所有权并反向移植稳定性和安全修复。我们不鼓励这样做,但认识到这让许多应用开发者更容易。
Beta 版本和错误修复
开发者想知道哪些版本可以安全使用。即使看似无辜的功能也可能在复杂的应用程序中引入回归。同时,锁定到固定版本是危险的,因为您忽略了自您版本发布以来可能出现的安全补丁和错误修复。我们的目标是在 package.json
中允许以下标准 semver 范围
- 使用
~2.0.0
仅允许与稳定性或安全相关的修复程序进入您的2.0.0
版本。 - 使用
^2.0.0
允许非破坏性的合理稳定的功能工作以及安全和错误修复。
关于第二点重要的是,使用 ^
的应用程序仍然应该能够期望合理的稳定性水平。为了实现这一点,SemVer 允许使用预发布标识符来指示特定版本尚未安全或稳定。
无论您选择什么,您都必须定期在您的 package.json
中提升版本,因为破坏性更改是 Chromium 生命周期的事实。
流程如下
- 所有新的主版本和次版本线都以 beta 系列开始,该系列由
beta.N
的 SemVer 预发布标签指示,例如2.0.0-beta.1
。在第一个 beta 版本之后,后续的 beta 版本必须满足以下所有条件- 更改是向后 API 兼容的(允许弃用)
- 满足我们的稳定性时间表的风险必须很低。
- 如果一旦发布 beta 版本后需要进行允许的更改,则会应用这些更改,并且预发布标签会递增,例如
2.0.0-beta.2
。 - 如果特定的 beta 版本被普遍认为是稳定的,它将作为稳定版本重新发布,仅更改版本信息。例如
2.0.0
。在第一个稳定版本之后,所有更改都必须是向后兼容的错误或安全修复。 - 如果一旦发布稳定版本后需要进行未来的错误修复或安全补丁,则会应用它们,并且补丁版本会递增,例如
2.0.1
。
具体来说,以上意味着
- 在 beta 周期的第 3 周之前允许非破坏性 API 更改是可以的,即使这些更改有可能导致中等程度的副作用。
- 在 beta 周期的绝大多数时间点允许功能标记更改(否则不会更改现有代码路径)是可以的。用户可以在他们的应用程序中显式启用这些标志。
- 在 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
发布。 - 一个错误修复进入 master 分支,可以反向移植到发布分支。应用该补丁,并以
2.0.0-beta.2
发布新的 beta 版本。 - 该 beta 版本被认为是普遍稳定的,并且再次以非 beta 版本
2.0.0
发布。 - 稍后,一个零日漏洞被揭露,并且修复程序被应用到 master 分支。我们将修复程序反向移植到
2-0-x
版本线,并发布2.0.1
。
一些 SemVer 范围如何获取新版本的示例
反向移植请求流程
所有受支持的发布版本线都将接受外部拉取请求,以反向移植先前合并到 main
的修复程序,尽管对于某些较旧的受支持版本线,这可能是个例。所有关于发布版本线反向移植的有争议的决定都将由 Releases Working Group 在他们每周会议的议程项目中解决,该周会提出反向移植 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.8.1
开发的应用程序无法在不吸收 1.8.2
功能的情况下获取 1.8.3
错误修复,或者通过反向移植修复程序并维护新的发布版本线。