Electron 版本管理

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

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

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

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

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

版本 2.0 和之后版本

我们的1.x战略有以下几项重大变化。 每次更改都是为了满足开发者/维护者和应用开发者的需要和优先事项。

  1. 严格使用 SemVer
  2. 引入符合 semver 的 -beta 标签
  3. 引入
  4. 明确定义的稳定分支

我们将详细介绍 git 分支是如何工作的，npm 标记是如何工作的，开发人员应该看到什么，以及如何能够支持更改。

从 2.0 开始，Electron 将遵循 SemVer。

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

稳定分支是与主控并行运行的分支，仅接受与安全性或稳定性有关的最优提交。 这些分支永远不会合并回 master 分支.

稳定分支

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

我们允许同时存在多个稳定分支，并且打算在任何时候至少支持两个并行支持安全修复。

GitHub不支持旧线路，但是其他分组可以自行获取所有权和返回稳定性和安全修复。 我们不鼓励这样做，但是认识到它使得许多应用程序开发人员的生活更轻松。

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

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

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

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

过程如下:

  1. All new major and minor releases lines begin with a beta series indicated by SemVer prerelease tags of beta.N, e.g. 2.0.0-beta.1. 在第一次测试后，测试版随后的释放必须满足以下所有条件：
    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. 接受特征标记的更改，这些更改不会改变现有的代码路径。在测试周期中的大多数点都是好的。 用户可以在他们的应用中明确启用那些标记。
  3. 第三周之后在测试周期内接纳任何类型的功能是 👎 没有很好的理由。

图片中的生命周期示例:

  • 创建了一个新的发行分支，包括最新的功能。 它会被发布为 2.0.0-beta.1。 新发行版
  • Bug 修复会被导入主，可以返回发布分支。 补丁已应用，一个新测试版已发布为 2.0.0-beta.2。
  • 之后有个 0day 漏洞被发现，然后对 master 采取了修复措施。 我们支持修复为 行，并释放 2.0.1。 安全移植

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

我们的战略有几次权衡，我们现在认为这是适当的。 最重要的是, 新的主分支特性可能需要一段时间才能作为稳定版发布。 如果你想立即尝试一个新的特性, 你必须自己编译Electron 。

作为未来的考虑, 我们可以介绍以下一种或两种情况:

  • 具有松散稳定性限制的 alpha 释放版; 例如, 当稳定通道在 alpha 中时, 允许接纳新特性

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

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

我们力求在更新和发布过程的各个层面提高清晰度。 从 2.0.0 开始, 我们将要求遵循 常规提交 规范的拉请求, 可以概括如下:

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

  • 会导致 SemVer minor 版本改变的提交必须以 feat: 开头。

  • 会导致 SemVer patch 版本改变的提交必须以 fix: 开头。

  • 只要pull request里包含有意义的总结性的版本语义消息，即使它其中的某些提交消息不包含版本语义前缀也是可以接受的

打了版本的 主分支

  • The master 分支将始终在其 package.json 中包含 0.0.0-dev.
  • Release 分支永远不会合并回 master 分支
  • 发布分支 在 其package.json 中包含正确的版本