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 系列开始,该系列由 SemVer 预发布标签
beta.N
指示,例如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
的修复,尽管对于某些较旧的受支持版本线,这可能是具体情况而定的。 有关发布版本线反向移植的所有有争议的决定将由 发布工作组 在其每周会议上作为议程项目来解决,会议时间为提出反向移植 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.3
错误修复,而无需吸收 1.8.2
功能,或者通过反向移植修复并维护新的发布版本线。