关于 Electron 项目的重要公告
查看所有标签
Electron 项目将在 2024 年 12 月暂停，然后在 2025 年 1 月恢复全速运行。
2025年再见！
Electron 项目将在 2023 年 12 月暂停，并于 2024 年 1 月恢复全面开发。
这是我们第三年尝试静默期实验，到目前为止，我们已成功地平衡了一个月的休息时间和之后保持正常发布节奏的需求。因此，我们决定将其作为我们发布日历的常规组成部分。我们仍会在每个日历年的最后一个稳定版本中添加提醒。
2024 年再见！
electron/electron 仓库的首次提交是在 2013 年 3 月 13 日1。
10 年间，来自 1192 位独立贡献者的 27,147 次提交，Electron 已成为当今最流行的桌面应用程序构建框架之一。这个里程碑是庆祝和反思我们迄今为止的旅程，并分享我们一路走来所学到的经验的绝佳机会。
如果没有各位投入时间和精力为项目做出贡献，我们今天就不会取得如此成就。尽管源代码提交始终是最显而易见的贡献，但我们也必须感谢那些报告 Bug、维护用户态模块、提供文档和翻译，以及在网络空间中参与 Electron 社区的人们所付出的努力。对于我们这些维护者来说，每一次贡献都弥足珍贵。
在继续阅读这篇博客文章之前：谢谢你。❤️
Atom Shell 是作为 GitHub Atom 编辑器的骨干而构建的，该编辑器于 2014 年 4 月发布公开测试版。它从头开始构建，旨在替代当时可用的基于网络的桌面框架（node-webkit 和 Chromium Embedded Framework）。它有一个杀手级功能：嵌入 Node.js 和 Chromium 以提供强大的桌面运行时，支持 Web 技术。
一年之内，Atom Shell 的功能和受欢迎程度开始大幅增长。大型公司、初创企业和个人开发者都开始使用它构建应用程序（一些早期采用者包括 Slack、GitKraken 和 WebTorrent），该项目也因此更名为 Electron。
从那时起，Electron 便一路高歌猛进，从未停歇。以下是我们的每周下载量随时间变化的图表，由 npmtrends.com 提供：
Electron v1 于 2016 年发布，承诺提供更稳定的 API、更好的文档和工具。Electron v2 于 2018 年发布，并引入了语义化版本控制，使 Electron 开发者更容易跟踪发布周期。
到 Electron v6 版本，我们转向了与 Chromium 匹配的每 12 周发布一个主要版本的节奏。这个决定改变了项目的理念，将“拥有最新的 Chromium 版本”从一个不错的选择提升为优先事项。这减少了升级之间的技术债务量，使我们更容易保持 Electron 的更新和安全。
从那时起，我们就像一台运转良好的机器，在每个 Chromium 稳定版发布的同一天发布一个新的 Electron 版本。到 2021 年 Chromium 将发布周期加快到 4 周时，我们能够轻松应对，并将发布节奏相应地加快到 8 周。
我们现在正使用 Electron v23（且仍在继续增长），并且仍然致力于为构建跨平台桌面应用程序提供最佳运行时。尽管近年来 JavaScript 开发工具蓬勃发展，但 Electron 仍然是桌面应用程序框架领域稳定、久经考验的中坚力量。Electron 应用程序如今无处不在：你可以使用 Visual Studio Code 编程，使用 Figma 进行设计，使用 Slack 进行交流，并使用 Notion 记笔记（以及许多其他用例）。我们为这一成就感到无比自豪，并感谢所有促成此事的人。
通往十周年的道路漫长而曲折。以下是一些帮助我们运营一个可持续的大型开源项目的关键经验。
当 Electron 首次流行起来后，我们必须克服的一个挑战是如何处理项目的长期发展方向。我们如何管理一个由分布在不同公司、国家和时区的几十名工程师组成的团队？
早期，Electron 的维护者团队依靠非正式协调，这对于小型项目来说快速且轻量，但无法扩展到更广泛的协作。2019 年，我们转向了治理模型，其中不同的工作组拥有正式的职责范围。这对于简化流程并将项目所有权的一部分分配给特定的维护者至关重要。如今，每个工作组 (WG) 负责什么？
大约在我们转向治理模型的同时，我们将 Electron 的所有权从 GitHub 转移到 OpenJS 基金会。尽管最初的核心团队今天仍在 Microsoft 工作，但他们只是构成 Electron 治理的更大协作组的一部分。2
虽然这个模式并非完美，但它在全球疫情和持续的宏观经济逆风中很好地支持了我们。展望未来，我们计划修订治理章程，以指导我们度过 Electron 的第二个十年。
如果你想了解更多信息，请查看 electron/governance 仓库！
开源的社区部分很难，特别是当你的外展团队是穿着风衣的十几名工程师，上面写着“社区经理”时。话虽如此，作为一个大型开源项目意味着我们拥有大量用户，利用他们的精力为 Electron 构建用户态生态系统是维持项目健康的关键部分。
我们为发展我们的社区做了些什么？
如今，Electron 治理团队拥有大约 30 名活跃的维护者。我们中只有不到一半是全职贡献者，这意味着有很多工作要做。我们保持一切顺利运行的秘诀是什么？我们的座右铭是：计算机很便宜，而人的时间很宝贵。本着典型的工程师精神，我们开发了一套自动化支持工具，让我们的生活更轻松。
Electron 核心代码库是一个庞大的 C++ 代码库，构建时间一直是我们在发布错误修复和新功能方面的一个限制因素。2020 年，我们部署了 Not Goma，这是一个针对 Google Goma 分布式编译器服务的自定义 Electron 后端。Not Goma 处理来自授权用户机器的编译请求，并将编译过程分配到后端数百个核心。它还缓存编译结果，以便其他人编译相同文件时只需下载预编译结果。
自从推出 Not Goma 以来，维护者的编译时间从几小时缩短到了几分钟。稳定的网络连接成为贡献者编译 Electron 的最低要求！
如果你是一名开源贡献者，你也可以尝试 Not Goma 的只读缓存，它在 Electron Build Tools 中默认可用。
持续因子认证 (CFA) 是 npm 双因素认证 (2FA) 系统之上的一层自动化，我们将其与 semantic-release 结合使用，以管理我们各种 @electron/ npm 包的安全和自动化发布。
虽然 semantic-release 已经自动化了 npm 包的发布过程，但它需要关闭双因素认证，或者传入一个绕过此限制的秘密令牌。
我们构建了 CFA，以便为任意的 CI 作业提供基于时间的一次性密码 (TOTP) 用于 npm 2FA，这使我们能够利用 semantic-release 的自动化，同时保持双因素认证的额外安全性。
我们使用 CFA 与一个 Slack 集成前端，允许维护者在任何装有 Slack 的设备上验证包的发布，只要他们手头有 TOTP 生成器。
Sheriff 是我们编写的一个开源工具，用于自动化管理 GitHub、Slack 和 Google Workspace 的权限。
Sheriff 的核心价值主张是权限管理应该是一个透明的过程。它使用单个 YAML 配置文件来指定上述所有服务的权限。使用 Sheriff，获得仓库的协作者状态或创建新的邮件列表就像获得 PR 批准和合并一样简单。
Sheriff 还有一个审计日志，会发布到 Slack，当 Electron 组织内任何地方发生可疑活动时，会警告管理员。
GitHub 是一个具有丰富 API 扩展性和第一方机器人应用框架 Probot 的平台。为了帮助我们专注于工作中更具创造性的部分，我们构建了一套小型机器人，帮助我们完成繁琐的工作。以下是一些例子：
总而言之，我们这个小小的机器人家族极大地提高了我们的开发效率！
当我们进入项目的第二个十年时，你可能会问：Electron 的下一步是什么？
我们将与 Chromium 的发布节奏保持同步，每 8 周发布一个 Electron 的新主要版本，使框架与 Web 平台和 Node.js 的最新和最强大的功能保持同步，同时保持企业级应用程序的稳定性和安全性。
我们通常会在即将推出的计划具体化时公布消息。如果您想了解未来的版本、功能和一般项目更新，您可以阅读我们的博客并关注我们的社交媒体资料（Twitter 和 Mastodon）！
这实际上是来自 electron-archive/brightray 项目的第一次提交，该项目于 2017 年并入 Electron 并合并了其 git 历史记录。但谁在乎呢？这是我们的生日，所以我们可以制定规则！↩
与普遍的看法相反，Electron 不再由 GitHub 或 Microsoft 拥有，现在是 OpenJS Foundation 的一部分。↩
从 Electron 23 开始，Electron 将结束对 Windows 7、Windows 8 和 Windows 8.1 的支持。
遵循 Chromium 的弃用策略，Electron 将在 Electron 23 中停止支持 Windows 7、Windows 8 和 Windows 8.1。这与 Microsoft 在 2023 年 1 月 10 日结束对 Windows 7 ESU 和 Windows 8.1 扩展支持 的计划一致。
Electron 22 将是最后一个支持 10 版本以下 Windows 版本的 Electron 主版本。Windows 7/8/8.1 将不在 Electron 23 及更高主版本中得到支持。旧版本的 Electron 将继续在 Windows 7 上运行，我们将继续为 Electron 22.x 系列发布补丁，直到 2023 年 5 月 30 日（根据我们的 支持时间表），届时 Electron 将停止支持 22.x。
Electron 遵循计划中的 Chromium 弃用策略，该策略将在 Chromium 109 中弃用支持（在此处阅读更多关于 Chromium 时间线的信息）。Electron 23 将包含 Chromium 110，而 Chromium 110 将不支持旧版本的 Windows。
因此，包含 Chromium 108 的 Electron 22 将是最后一个受支持的版本。
以下是我们计划的弃用时间表
这对开发者意味着什么
2023/02/16：关于 Windows Server 2012 支持的更新
上个月，Google 宣布 Chrome 109 将继续接收 Windows Server 2012 和 Windows Server 2012 R2 的关键安全修复程序，直至 2023 年 10 月 10 日。因此，Electron 22（Chromium 108）的计划生命周期结束日期将从 2023 年 5 月 30 日延长至 2023 年 10 月 10 日。Electron 团队将继续将此计划中的任何安全修复程序向后移植到 Electron 22，直至 2023 年 10 月 10 日。
请注意，我们不会为 Windows 7/8/8.1 提供额外的安全修复。此外，如先前宣布，Electron 23 (Chromium 110) 将只在 Windows 10 及以上版本运行。
如果您有任何疑问或疑虑，请随时通过 info@electronjs.org 与我们联系。您也可以在我们官方的 Electron Discord 中找到社区支持。
Electron 项目将在 2022 年 12 月暂停，并于 2023 年 1 月恢复全速运行。
鉴于2021年12月寂静月（Quiet Month）的成功，我们希望在2022年再次举办。对大多数公司来说，12月仍然是一个比较平静的月份，所以我们希望让我们的维护者有机会好好充电。每个人都在期待2023年，我们预计会有好事情发生！我们鼓励其他项目考虑采取类似的措施。
上个月，Electron 维护者团队在加拿大温哥华会面，讨论了该项目在 2023 年及以后的发展方向。在会议室里，核心维护者和特邀合作者们用了四天时间讨论了新举措、维护痛点以及项目的整体健康状况。
合影！由 @groundwater 拍摄。
未来，团队将继续全力致力于定期快速发布 Chromium 更新、修复 bug，并让 Electron 对所有人来说更安全、性能更好。我们还有一些令人兴奋的项目正在开发中，非常乐意与社区分享！
Electron 项目中需要达成共识的主要 API 提案，会通过“征求意见”（RFC）流程，由我们的 API 工作组的成员进行审查。
今年，我们推动了两项可能为 Electron 应用解锁新维度能力的重大提案。这些提案仍是高度实验性的，但以下是我们对即将到来的内容的抢先预览！
本提案概述了 Electron C API 的一个新层，该层将允许应用程序开发人员编写自己的原生 Node 插件，这些插件可以与 Electron 的内部资源进行交互，类似于 Node 本身的 Node-API。有关提议的新 API 的更多信息，可以在这里找到。
许多 Electron 应用程序维护着自己的分支，以便直接与 Chromium 内部组件交互，而这些组件在普通（未修改）的 Electron 中是无法访问的。通过在 C API 层公开这些资源，这些代码可以作为原生模块与 Electron 一起存在，从而可能减轻应用程序开发者的维护负担。
在底层，Chrome 用户界面（UI）的非网站部分（例如工具栏、标签页或按钮）是使用一个名为 Views 的框架构建的。Views API 提案将该框架的部分内容引入 Electron 中的 JavaScript 类，最终目标是允许开发人员为其 Electron 应用程序创建非 Web UI 元素。这将使应用程序无需拼凑 Web 内容。
使这套新 API 成熟的基础工作正在进行中。以下是我们可以在不久的将来看到的一些首批成果。
WebContentsView 重构窗口模型我们计划进行的第一个更改是向 Electron 的 API 表面公开 Chrome 的 WebContentsView，它将是我们现有 BrowserView API 的继任者（尽管名称如此，但 BrowserView API 是 Electron 特有的代码，与 Chromium Views 无关）。通过公开 WebContentsView，我们将拥有一个可重用的 View 对象，可以显示 Web 内容，为使 BrowserWindow 类成为纯 JavaScript 并消除更多代码复杂性打开了大门。
虽然这个更改没有为应用开发者提供太多新功能，但它是一个大型重构，消除了大量的底层代码，简化了 Chromium 升级，并降低了主要版本之间出现新 bug 的风险。
如果您是 Electron 应用开发者，并且正在使用 BrowserViews：请放心，我们没有忘记您！我们计划将现有的 BrowserView 类变成 WebContentsView 的一个包装器，为您向较新的 API 过渡提供缓冲。
参见：electron/electron#35658
ScrollView 进行可滚动 Web 内容我们 Stack 的朋友们一直在推动一项将 Chromium ScrollView 组件公开给 Electron API 的举措。有了这个新 API，任何子 View 组件都可以设置为水平或垂直滚动。
虽然这个新 API 只实现了单一的小功能，但团队的最终目标是构建一套工具性的 View 组件，可以作为工具包来构建更复杂的非 HTML 界面。
您是对这两个 API 提案感兴趣的 Electron 应用开发者吗？虽然我们还没有准备好接收额外的 RFC，但请继续关注未来更多详情！
自框架问世以来，Electron 的构建工具生态系统在很大程度上是社区驱动的，并且由许多小型单一用途的包组成（例如 electron-winstaller、electron-packager、electron-notarize、electron-osx-sign）。尽管这些工具运行良好，但用户需要拼凑一个可用的构建流水线，这让他们望而却步。
为了帮助为 Electron 开发人员构建更友好的体验，我们构建了 Electron Forge，这是一个一体化解决方案，将所有现有工具整合到一个单一的界面中。尽管 Forge 自 2017 年以来一直在开发中，但在过去的几年里该项目一直处于停滞状态。然而，考虑到社区对 Electron 构建工具状态的反馈，我们一直在努力发布下一代 Forge 的稳定主版本。
Electron Forge 6 提供了对 TypeScript 和 Webpack 的一流支持，以及一个可扩展的 API，允许开发者创建自己的插件和安装程序。
如果您有兴趣使用 Forge 构建项目，或者使用 Forge 的可扩展第三方 API 构建模板或插件，请在本月晚些时候关注我们关于 Forge v6 稳定版发布的官方公告！
除上述内容外，团队一直在考虑许多探索性项目，以改善应用程序开发者和最终用户的 Electron 体验。更新工具、API 审查流程和增强的文档是我们正在试验的其他一些项目。我们希望在不久的将来分享更多消息！
Electron 21 及更高版本将启用 V8 内存笼，这对一些原生模块有影响。
要跟踪关于 Electron 21+ 中原生模块使用的持续讨论，请参阅 electron/electron#35801。
在 Electron 21 中，我们将启用 V8 沙盒指针，遵循 Chrome 在 Chrome 103 中采取的相同决策。这对于原生模块有一些影响。此外，我们之前在 Electron 14 中启用了相关技术，即 指针压缩。当时我们没有过多讨论，但指针压缩对 V8 堆的最大大小有影响。
这两种技术在启用后，在安全性、性能和内存使用方面都有显著的好处。然而，启用它们也有一些缺点。
启用沙盒指针的主要缺点是，指向外部（“堆外”）内存的 ArrayBuffers 不再被允许。这意味着依赖 V8 中此功能的原生模块需要重构才能在 Electron 20 及更高版本中继续工作。
启用指针压缩的主要缺点是，V8 堆被限制为最大 4GB。具体细节有些复杂——例如，ArrayBuffers 与 V8 堆的其余部分分开计算，但有它们 自己的限制。
Electron 升级工作组 认为指针压缩和 V8 内存笼的优点大于缺点。这样做主要有三个原因：
最后，对于确实需要更大堆大小的应用程序，有解决方法。例如，可以在应用程序中包含一个禁用了指针压缩的 Node.js 副本，并将内存密集型工作转移到子进程。虽然有些复杂，但如果您的特定用例需要不同的权衡，也可以构建一个禁用了指针压缩的自定义 Electron 版本。最后，在不远的将来，wasm64 将允许使用 WebAssembly 构建的应用程序（无论是在 Web 上还是在 Electron 中）使用超过 4GB 的内存。
尝试使用 ArrayBuffer 包装外部内存将在 Electron 20+ 中导致运行时崩溃。
如果您的应用程序中没有使用任何原生 Node 模块，那么您是安全的——无法从纯 JS 触发此崩溃。此更改仅影响那些在 V8 堆之外分配内存（例如使用 malloc 或 new），然后用 ArrayBuffer 包装外部内存的原生 Node 模块。这是一种相当罕见的用例，但有些模块确实使用了这种技术，并且此类模块需要重构才能与 Electron 20+ 兼容。
在渲染器进程中，您可以使用 performance.memory.usedJSHeapSize，它将以字节为单位返回 V8 堆使用量。在主进程中，您可以使用 process.memoryUsage().heapUsed，它是可比较的。
有些文档将其称为“V8 沙盒”，但该术语容易与 Chromium 中发生的 其他类型的沙盒 混淆，因此我将坚持使用“内存笼”这个术语。
有一种相当常见的 V8 漏洞利用方式，大致如下：
V8 内存笼是一种旨在彻底防止此类攻击的技术。实现方式是**不在 V8 堆中存储任何指针**。相反，所有对 V8 堆内部其他内存的引用都以某个保留区域开头的偏移量存储。这样，即使攻击者设法破坏 ArrayBuffer 的基地址，例如通过利用 V8 中的类型混淆错误，他们最坏也只能在笼内读写内存，而这他们本来可能就已经可以做到了。关于 V8 内存笼的工作原理还有很多可读的资料，因此我不会在此处深入探讨——最好的起点可能是 Chromium 团队的 高级设计文档。
有两种方法可以重构原生模块以使其与 V8 内存笼兼容。第一种方法是，在将外部创建的缓冲区传递给 JavaScript 之前，将其**复制**到 V8 内存笼中。这通常是一个简单的重构，但当缓冲区很大时可能会很慢。另一种方法是**使用 V8 的内存分配器**来分配您打算最终传递给 JavaScript 的内存。这有点复杂，但可以避免复制，这意味着对于大缓冲区来说性能更好。
为了使这一点更具体，这里有一个使用外部 ArrayBuffer 的 N-API 模块示例
// Create some externally-allocated buffer.
// |create_external_resource| allocates memory via malloc().
size_t length = 0;
void* data = create_external_resource(&length);
// Wrap it in a Buffer--will fail if the memory cage is enabled!
napi_value result;
napi_create_external_buffer(
env, length, data,
finalize_external_resource, NULL, &result);
当启用内存笼时，这会崩溃，因为数据是在笼子外面分配的。重构为复制数据到笼子中，我们得到：
size_t length = 0;
void* data = create_external_resource(&length);
// Create a new Buffer by copying the data into V8-allocated memory
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// If you need to access the new copy, |copied_data| is a pointer
// to it!
这将数据复制到一个新分配的内存区域，该区域位于 V8 内存笼内。可选地，N-API 还可以提供指向新复制数据的指针，以防您需要在事后修改或引用它。
重构以使用 V8 的内存分配器要复杂一些，因为它需要修改 create_external_resource 函数以使用 V8 分配的内存，而不是使用 malloc。这可能或多或少可行，具体取决于您是否控制 create_external_resource 的定义。其思想是首先使用 V8 创建缓冲区，例如使用 napi_create_buffer，然后将资源初始化到 V8 分配的内存中。重要的是要为 资源的生命周期 保留对 Buffer 对象的 napi_ref，否则 V8 可能会垃圾回收 Buffer，并可能导致 use-after-free 错误。
Electron 正在更改其主要的 S3 存储桶，您可能需要更新您的构建脚本
Electron 的大量构建产物被上传到一个名为 gh-contractor-zcbenz 的 S3 存储桶。作为自 2020 年开始的持续的基础设施/所有权迁移的一部分，我们将把所有使用 gh-contractor-zcbenz 的内容从 S3 中的旧位置迁移到一个托管在 https://artifacts.electronjs.org 的新存储系统中。我们大多数资源使用的路径前缀也会略有改变。下方包含示例
之前： https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib 之后： https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib
这里重要的是 **主机名** 发生了变化，并且 /atom-shell **前缀** 也发生了变化。另一个例子，这次是关于调试符号
之前： https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb 之后： https://artifacts.electronjs.org/symbols/path/to/symbol.pdb
同样，主机名发生了变化，并且 /atom-shell 前缀也被更改了。
任何使用标准构建工具（如 electron-rebuild、electron-packager 或 @electron/get）的人都不需要做任何事情。这应该占大多数人。
对于任何直接引用 S3 存储桶的人，您必须更新您的引用，使其指向新的主机名并更新路径。
gh-contractor-zcbenz 存储桶中存在的大部分数据已被克隆到新的存储系统中。这意味着所有调试符号和所有头文件都已复制。如果您依赖该存储桶中的某些未复制的数据，请在 electron/electron 中提出一个 issue 并告知我们。
当前的 gh-contractor-zcbenz S3 存储桶不会被主动删除。但是，我们不能保证该存储桶将保留多长时间。我们 **强烈** 建议尽快更新以指向新的存储桶。
Electron 项目将在 2021 年 12 月暂停一个月，然后在 2022 年 1 月恢复全速运行。
简而言之，虽然维护者对项目感到满意并积极参与，但世界已经厌倦了。十二月是大多数公司的一个平静的月份，所以我们希望给我们的维护者一个休息的机会。我们鼓励其他项目考虑类似的措施。
不用担心。我们之所以能采取这一步，是因为项目正处于良好状态。大家都对 2022 年充满期待，我们预计会有美好的事情发生！
从2021年9月开始，Electron 将每8周发布一个主要稳定版本。
2019 年，Electron 调整为 12 周发布周期，以匹配 Chromium 的 6 周发布周期。最近，Chrome 和 Microsoft 都宣布了让我们重新考虑 Electron 当前发布周期的变更。
Chromium 计划从 2021 年 9 月 21 日的 Chrome 94 开始，每 4 周发布一个新里程碑。此发布周期还每 8 周增加一个新的 Extended Stable 选项，其中包含所有更新的安全修复程序。
Microsoft Store 将要求基于 Chromium 的应用版本不得早于最新的两个主版本。例如，如果 Chromium 的最新发布主版本是 85，则任何基于 Chromium 的浏览器必须至少为 Chromium 版本 83 或更高版本。此规则包括 Electron 应用。
从2021年9月开始，Electron将每8周发布一个新的主要稳定版本，以匹配Chromium的8周长期支持（Extended Stable）版本。
我们第一个使用Chromium长期支持版本（Extended Stable）的发布将是2021年9月21日的Electron 15。
我们知道发布周期调整将影响其他下游应用程序，因此我们希望尽快告知我们的开发者社区。请继续阅读以了解有关我们2021年发布计划的更多详细信息。
鉴于我们最初的 Electron 15 发布目标是非 Extended Stable 版本（Chromium 的 Extended Stable 版本基于其偶数版本），我们需要更改原始目标发布日期。然而，Electron 应用必须使用最新的两个 Chromium 主版本才能被 Microsoft Store 接受，这使得等待两个 Chromium 版本变得不可行。
考虑到这两个要求，我们的团队面临着一个时间上的困境。将 Electron 15 迁移到包含 Chromium M94 将允许应用开发者使用 Chromium 的第一个 Extended Stable 版本；然而，这也会将 beta 到 stable 的周期缩短到只有 3 周。
为了帮助实现这一过渡，Electron 将为 Electron 15 发布提供一个临时的 alpha 构建版。此 alpha 构建版将为开发者提供更多时间来测试和规划 Electron 15 的发布，其稳定性将高于我们当前的 nightly 构建版。
alpha 通道构建版将于 2021 年 7 月 20 日发布 Electron 15。它将于 2021 年 9 月 1 日过渡到 beta 版本，稳定发布目标为 2021 年 9 月 21 日。此后的 Electron 发布将不再提供 alpha 版本。
以下是我们的2021年当前发布计划：
| Electron | Chrome | Alpha 版本 | Beta 版本 | 稳定版本 | 稳定周期（周） |
|---|---|---|---|---|---|
| E13 | M91 | - | 2021-03-05 | 2021-05-25 | 12 |
| E14 | M93 | - | 2021-05-26 | 2021-08-31 | 14 |
| E15 | M94 | 2021-07-20 | 2021-09-01 | 2021-09-21 | 9 (包含 alpha) |
| E16 | M96 | - | 2021-09-22 | 2021-11-16 | 8 |
| E17 | M98 | - | 2021-11-17 | 2022-02-01 | 11 |
添加 alpha 通道将 Electron 15 发布前的开发时间从3周延长到9周——更接近我们新的8周周期，同时仍满足Windows商店的提交要求。
为了进一步帮助应用开发者，在 2021 年剩余时间直至 2022 年 5 月，我们将把支持版本策略从最新的 3 个版本扩展到最新的 4 个 Electron 版本。这意味着即使您无法立即更改升级计划，旧版本的 Electron 仍将获得安全更新和修复。
我们之所以在这个发布周期变化预定之前发布这篇文章，是有原因的。我们知道更快的发布周期将对Electron应用程序产生实际影响——其中一些应用程序可能已经觉得我们的大版本发布周期很激进了。
我们已尝试在下方解决常见疑虑：
为了在 Electron 中提供最新的 Chromium 版本，我们的计划需要与他们的计划保持一致。有关 Chromium 发布周期的更多信息，请参阅此处。
此外，当前的 12 周发布周期将无法满足 Microsoft Store 的新提交要求。即使是最新稳定版 Electron 的应用，在新的安全要求下，也可能会经历大约两周的应用被拒绝期。
每个新的 Chromium 版本都包含新功能、错误修复/安全修复和 V8 改进。我们希望您（作为应用开发者）能够及时获得这些更改，因此我们的稳定发布日期将继续与每隔一个 Chromium 稳定版本保持一致。作为应用开发者，您将比以前更快地获得新的 Chromium 和 V8 功能及修复。
更频繁发布的优势之一是发布版本更小。我们理解升级 Electron 的主版本可能很困难。我们希望较小的发布版本在每次发布时引入的 Chromium 和 Node 主要更改以及破坏性更改会更少。
目前没有计划支持永久性的alpha版本。这个alpha版本仅针对Electron 15，作为一种帮助开发者在缩短的发布周期内更轻松地升级的方式。
我们将把支持版本策略从最新的三个版本延长到最新的四个 Electron 版本，直至 2022 年 5 月 Electron 19 发布。在 Electron 19 发布后，我们将恢复支持最新的三个主版本，以及 beta 和 nightly 版本。
| E13 (2021年5月) | E14 (2021年8月) | E15 (21年9月) | E16 (21年11月) | E17 (22年2月) | E18 (22年3月) | E19 (22年5月) |
|---|---|---|---|---|---|---|
| 13.x.y | 14.x.y | 15.x.y | 16.x.y | 17.x.y | 18.x.y | 19.x.y |
| 12.x.y | 13.x.y | 14.x.y | 15.x.y | 16.x.y | 17.x.y | 18.x.y |
| 11.x.y | 12.x.y | 13.x.y | 14.x.y | 15.x.y | 16.x.y | 17.x.y |
| -- | -- | 12.x.y | 13.x.y | 14.x.y | 15.x.y | -- |
📨 如果您有任何问题或疑虑，请通过 info@electronjs.org 发送邮件给我们，或加入我们的 Discord。我们知道这对许多应用和开发者都会产生影响，您的反馈对我们非常重要。我们希望能听到您的声音！