2022年12月Electron项目将进入暂停状态，然后在2023年1月全速恢复。
With the success of December Quiet Month 2021, we wanted to bring it back for 2022. 对于大多数公司来说，12 月仍然是一个安静的月份，所以我们希望给我们的维护者一个充电的机会。 每个人都期待着2023年的到来，我们期待着会有好事！ 我们鼓励其他项目考虑采取类似措施。
我们很高兴地宣布 Electron Forge v6.0.0 现已推出！ 此版本标志着自 2018 年以来 Forge 的第一个主要版本，并将该项目从 electron-userland 转移到 GitHub 上的 electron 组织。
继续阅读以了解新功能以及您的应用如何调用 Electron Forge！
Electron Forge 是一个用于打包和分发 Electron 应用程序的工具。 它将 Electron 的构建工具生态系统统一到一个可扩展的界面中，这样每个人都可以直接上手制作 Electron 应用。
它的亮点：
访问 Why Electron Forge 文档，了解更多关于 Forge 的理念和架构信息。
从 v1 到 v5，Electron Forge 是在现已停止的 electron-compile 项目的基础上进行开发的。 Forge 6 是对项目的完全重构，具有新的模块化架构，可以扩展以满足大多数 Electron 应用程序的需求。
在过去的几年里，Forge v6.0.0-beta 已经实现了与 v5 相同的功能，并且代码流失速度显着放缓，使该工具为普遍采用做好了准备。
对于 v5 及更低的版本，Electron Forge 已在 npm 上发布了 electron-forge 包。 从 v6 重写开始，Forge 被设计为一个带有许多较小项目的 monorepo 项目。
从历史上看，Electron 的维护者对构建工具不感兴趣，而是把这个任务留给各个由社区维护的工具包。 然而，随着 Electron 项目的成熟，新的 Electron 开发人员越来越难以理解他们需要哪些工具来构建和分发他们的应用程序。
为了在分发过程中帮助指导 Electron 开发人员，我们决定让 Forge 成为 Electron 的官方内置的构建体系。
在过去的一年里，我们一直在慢慢地将 Forge 集成到官方的 Electron 文档中，最近我们将 Forge 从其在 electron-userland/electron-forge 的旧地址转移到了 electron/forge 存储库。 现在，我们终于准备好向广大用户发布 Electron Forge 了！
可以使用 create-electron-app CLI 脚本来搭建一个新的 Electron Forge 项目。
yarn create electron-app my-app --template=webpack
cd my-app
yarn start
npm init electron-app@latest my-app -- --template=webpack
cd my-app
npm start
该脚本将在 my-app 文件夹中创建一个 Electron 项目，其中包含完整的 JavaScript Bundling 及预先配置好的构建体系。
有关详细信息，请参阅 Forge 文档中的入门指南。
上面的代码片段使用了 Forge 的 Webpack 模板，我们建议将其作为新 Electron 项目的初始化配置。 此模板是围绕 @electron-forge/plugin-webpack 插件构建的，该插件以几种方式将 webpack 与 Electron Forge 集成，包括：
如果您需要 TypeScript 支持，请考虑改用 Webpack + TypeScript 模板。
Electron Forge CLI 还包含现有 Electron 项目的导入命令。
cd my-app
yarn add --dev @electron-forge/cli
yarn electron-forge import
cd my-app
npm install --save-dev @electron-forge/cli
npm exec --package=@electron-forge/cli -c "electron-forge import"
当您使用 import 命令时，Electron Forge 将添加一些核心依赖项并创建一个新的 forge.config.js 配置。 如果您有任何现有的构建工具（例如 Electron Packager、Electron Builder 或 Forge 5），它将尝试迁移尽可能多的设置。 您的某些现有配置可能需要手动迁移。
手动迁移详细信息可以在 Forge 导入文档中找到。 如果您需要帮助，请访问我们的 Discord 服务器！
如果您已经有了用于打包和发布 Electron 应用程序的工具，那么采用 Electron Forge 带来的好处仍然可以超过最初地转换成本。
我们认为使用 Forge 有两个主要好处：
Forge 在 Electron 支持的新功能出现后，会立即得到这些新功能并用于应用程序的构建。 在这种情况下，您不需要自己编写新的工具去实现，或者在升级之前等待其他更新包实现。 有关最近的示例，请参阅 macOS 通用二进制文件和 ASAR 完整性检查。
Forge 的多包架构使其易于理解和扩展。 是由于 Forge 由许多具有明确职责的较小包组成，因此更容易遵循代码流。 此外，Forge 的可扩展 API 设计意味着你可以在所提供的配置选项之外为高级用例编写自己的额外构建逻辑。 有关编写自定义 Forge 插件、制作者和发布者的更多详细信息，请参阅文档的扩展 Electron Forge 部分。
Forge 6 已经在 beta 阶段花了很长时间，它的发布节奏也逐渐放缓。 然而，我们在 2022 年下半年加速了开发，并利用在 v6.0.0 稳定版本之前的最后几个版本推出了一些最终的重大更改。
如果您是 Electron Forge 6 测试版用户，请参阅 v6.0 GitHub 更新日志 了解最近测试版中所做的重大变更 (>=6.0.0-beta.65)。
完整的更改和提交列表可以在仓库的 CHANGELOG.md 中找到。
告诉我们您的想法！ Electron Forge 团队一直在尝试提升用户在构建项目时候的开发体验。
您可以通过提交功能请求、提交 issues 或直接联系我们来进行反馈及改进 Electron Forge！ 您也可以加入我们的 官方 Electron Discord 英文社区，那里有一个专门用于 Electron Forge 讨论的频道。
如果您想在 https://electronforge.io 上对 Forge 文档提供任何反馈，我们有一个 GitBook 实例同步到 electron-forge/electron-forge-docs 存储库。
上个月，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 元素。 这将避免应用程序不得不将网页内容集中在一起。
使这套新的 API 成为可能的基础工作目前正在进行之中。 以下是您在不久的将来可以期待的一些事。
WebContentsView我们计划的第一次更改是在 Electron 的 API 中显示 Chrome 的 WebContentsView。这将 是我们现有的 BrowsView API 的继承者(尽管该名称是 Electron 指定的代码 与 Chromium 视图无关)。 随着 WebContentsView 暴露，我们将有一个可重用的 View 对象 可以显示网页内容，为使 BrowserWindow 类成为纯粹的 JavaScript 打开了大门。 更多的消除了代码复杂性。
尽管此更改并未为应用程序开发人员提供很多新功能，但它是一个大型重构，消除了许多底层代码，简化了 Chromium 升级并减少主要版本之间出现新错误的风险。
如果您是一个使用 BrowserViews 的 Electron 开发者，请勿担心，我们没有忘记您！ 我们计划将现有的 BrowserView 类变成一个 WebContentsView 的垫片（shim），以便在您过渡到较新的 API 时提供一个缓冲。
见: electron/electron#35658
ScrollView 滚动网页我们在 Stack 的朋友一直在推动一项倡议，将 Chromium ScrollView 组件暴露给 Electron 的 API。 通过这个新的 API，任何子视图组件都可以水平滚动或 垂直滚动。
尽管这个新的 API 实现了一个较小的功能，但该团队的最终目标是建立 一套实用的视图组件，可以作为一个工具包来构建更复杂的非 HTML 接口。
你是 Electron 应用程序的开发者，对这些 API 提案感兴趣吗？ 虽然我们还没有准备好接收更多的 RFC，但请继续关注未来的更多细节!
自从该框架诞生以来，Electron 的构建工具生态系统在很大程度上是由社区驱动的。 社区驱动的，由许多小型的单用途包组成(例如 electron-installer, 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.0.0 已发布！ 此次升级中包含 Chromium 106, V8 10.6, 和 Node.js 16.16.0。 请阅读下文了解更多详情！
Electron 团队很高兴发布了 Electron 21.0.0！ 您可以通过 npm install electron@latest 进行安装，或者从我们的 发布网站 下载它。 继续阅读此版本的详细信息。
如果您有任何反馈，请在Twitter上与我们分享，或加入我们的社区 Discord！ Bug 和功能请求可以在 Electron 的 问题跟踪器 中报告。
106
16.16.0
10.6webFrameMain.origin。 #35534WebContents.ipc 和 WebFrameMain.ipc API。 #35231以下是 Electron 21 中引入的破坏性变更。
Electron 21 启用 V8 沙盒指针，继 Chrome 决定在 Chrome 103 做同样的事情。 这对原生模块有一定的影响。 此功能具有性能和安全优势，但也对原生模块施加了一些新的限制，例如，使用指向外部（“堆外”）内存的 ArrayBuffers。 更多信息请查看 博客文章。 #34724
重构了 webContents.printToPDF 以与 Chromium headless 实现对齐。 更多信息请见 #33654。
有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。
根据项目的支持政策，Electron 18.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。
| E18 (2022年3月) | E19 (2022年5月) | E20 (2022年8月) | E21 (2022年9月) | E22 (2022年12月) |
|---|---|---|---|---|
| 18.x.y | 19.x.y | 20.x.y | 21.x.y | 22.x.y |
| 17.x.y | 18.x.y | 19.x.y | 20.x.y | 21.x.y |
| 16.x.y | 17.x.y | 18.x.y | 19.x.y | 20.x.y |
在短期内，你可以期待我们的团队继续专注于跟上构成 Electron 的主要组件的发展，包括 Chromium、Node 和 V8。
您可以在此处找到 Electron的公开时间表。
有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。
Electron 20.0.0 已发布！ 它包括升级到 Chromium 104, V8 10.4, 和 Node.js 16.15.0。 请阅读下文了解更多详情！
Electron 团队很高兴发布了 Electron 20.0.0！ 您可以通过 npm install electron@latest 进行安装，或者从我们的 发布网站 下载它。 继续阅读有关此版本的详细信息，并请分享您的任何反馈！
nodeIntegration: true 或 sandbox: false。 #35125104
16.15.0
10.4以下是 Electron 20 中引入的破坏性变化。 有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。
nodeIntegration: true 将进行沙盒处理之前, 指定预加载脚本的渲染器默认不启用沙盒。 这意味着默认情况下，预加载脚本可以访问Node.js。 在 Electron 20中，此默认值将被更改。 从Electron 20开始，渲染器 默认情况下会被沙盒化，除非指定了 nodeIntegration: true 或 sandbox: false 。
如果预加载脚本不依赖于 Node，则无需执行任何操作。 如果 preload 脚本依赖于 Node，请重构代码，或从渲染器中删除 Node 用法 ，或者显式指定相关渲染器 sandbox: false 。
在 Electron 20 中，我们更改了两个与原生模块相关的项目：
c++17 。 这个标志已添加到 electron-rebuild 了。为了获得最大的稳定性，我们建议在重新构建原生模块时使用 node-gyp >= 8.4.0 和 electron-rebuild >= 3.2.9，特别是依赖于nan的模块。 有关更多信息，请参阅 electron #35160 和 node-gyp #2497 。
.skipTaskbar在 X11上, skipTaskbar 向 X11 窗口管理器发送一条 _NET_WM_STATE_SKIP_TASKBAR 消息。 Wayland 没有与其一致的功能，并且已知的 变通办法具有不可接受的理由（如，在 GNOME 中 Window.is_skip_taskbar 需要不安全模式），因此 Electron 无法在 Linux 上支持此功能。
根据项目的支持政策，Electron 17.x.y 已经达到了支持的终点。 我们鼓励开发者和应用程序升级到更新的 Electron 版本。
| E18 (3月22日) | E19 (5月22日) | E20 (8月22日) | E21 (2022年9月) | E22 (2022年12月) |
|---|---|---|---|---|
| 18.x.y | 19.x.y | 20.x.y | 21.x.y | 22.x.y |
| 17.x.y | 18.x.y | 19.x.y | 20.x.y | 21.x.y |
| 16.x.y | 17.x.y | 18.x.y | 19.x.y | 20.x.y |
| 15.x.y | -- | -- | -- | -- |
在短期内，你可以期待我们的团队继续专注于跟上构成 Electron 的主要组件的发展，包括 Chromium、Node 和 V8。 虽然我们谨慎地不对发布日期做出承诺，但我们的计划是大约每2个月发布一次带有新版本组件的主要版本的 Electron。
您可以在此处找到 Electron的公开时间表。
有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。
Electron 21及更高版本将启用 V8 内存隔离区，这将对一些原生模块产生影响。
To track ongoing discussion about native module usage in Electron 21+, see electron/electron#35801.
在Electron 21中，我们将启用 V8沙盒指针， Electron中，Chrome 决定在Chrome 103中执行相同的操作。 这对原生模块有一定的影响。 此外，我们曾在 Electron 14 中启用了 指针压缩 相关技术。 我们当时没有对此进行过多地讨论，但指针压缩对V8最大堆大小有影响。
这两种技术一旦启用，将对安全、性能和内存使用大有裨益。 但是，启用它们也有一些缺点。
启用沙盒指针的主要缺点是，不再允许进行指向外部 ("off-heap") 内存 的数组缓冲区的操作。 这意味着在V8中依赖于此功能的原生模块将需要重构才能在Electron 20及更高版本中继续工作。
启用指针压缩的主要缺点是， V8堆的最大大小限制为4GB。 这方面的确切细节有点复杂 - 例如，ArrayBuffers与V8堆的其余部分分开计数，但存在一些 自己的限制。
Electron 升级团队 认为，启用指针压缩和V8内存隔离区的好处超过了缺点。 这样做主要有三个原因：
最后，对于确实需要更多堆大小的应用，有一些解决方法。 例如，可以在应用（在禁用指针压缩的情况下生成）中包含 Node.js 的副本，并将占用大量内存的工作移动到子进程。 虽然有些复杂，但如果您决定要为特定用例进行不同的权衡，也可以构建禁用指针压缩的Electron的自定义版本。 最后，在不久的将来， wasm64 将允许在Web和Electron中使用WebAssembly构建的应用程序使用超过4GB的内存。
尝试使用ArrayBuffer包装外部存储器将在Electron 20 +的运行时崩溃。
如果你没有在应用中使用任何原生 Node 模块，那么你是安全的 - 目前没有办法从纯 JS 触发此崩溃。 此更改仅影响原生 Node 模块，这些模块在 V8 堆之外分配内存（例如，使用 malloc 或 new），然后使用 ArrayBuffer 包装外部内存。 这是一个相当罕见的用例，但有些模块确实使用这种技术，并且这些模块需要重构才能与Electron 20 +兼容。
在渲染器进程中，您可以使用 performance.memory.usedJSHeapSize，这将返回 V8 堆使用情况（以字节为单位）。 在主过程中，您可以使用 process.memoryUsage().heapUsed，这是可比较的。
一些文档将其称为“V8沙盒”，但该术语很容易与Chromium中发生的 其他类型的沙盒 混淆，因此我将坚持使用术语“内存隔离区”。
有一种相当常见的V8漏洞利用，如下所示：
V8 内存隔离区是一种旨在明确防止此类攻击的技术。 实现此目的的方法是 _不在 V8 堆_存储任何指针。 相反，对 V8 堆内其他内存的所有引用都存储为从某个保留区域的开头开始的偏移量。 然后，即使攻击者设法破坏了ArrayBuffer的基址，例如通过利用V8中的类型混淆错误，他们能做的最糟糕的事情就是在笼子里读取和写入内存，他们可能已经这样做了。 关于V8内存隔离区的工作原理还有很多可供阅读的内容，所以我不会在这里进一步详细介绍 - 开始阅读的最佳位置可能是Chromium团队 高级设计文档。
有两种方法可以重构原生模块以使其与 V8 内存隔离区兼容。 第一种方法是 **** 外部创建的缓冲区复制到 V8 内存笼中，然后再将它们传递给 JavaScript。 这通常是一个简单的重构，但是当缓冲区很大时，它可能会很慢。 另一种方法是 使用 V8 的内存分配器 来分配你打算最终传递给 JavaScript 的内存。 这有点复杂，但可以避免复制，这意味着大型缓冲区的性能更好。
为了更具体地说明这一点，下面是一个使用外部数组缓冲区的示例 N-API 模块：
// 创建一些外部分配的缓冲区。
// |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 进行垃圾回收，并可能导致释放后使用错误。
Electron 19.0.0 已发布！ 它包括升级到 Chromium 102, V8 10.2, 和 Node.js 16.14.2。 请阅读下文了解更多详情！
Electron 团队很高兴发布了 Electron 19.0.0！ 您可以通过 npm install electron@latest 进行安装，或者从我们的 发布网站 下载它。 继续阅读有关此版本的详细信息，并请分享您的任何反馈！
该项目正在恢复其支持最新三个主要版本的早期政策。 查看我们的版本文档 以了解更多关于 Electron 版本控制和支持的详细信息。 暂时有四个主要版本，以帮助用户适应从 Electron 15 开始的新版本发布节奏。 您可以在此处阅读 完整详细信息。
102
16.14.2
10.2以下是 Electron 19 中引入的破坏性变化。 有关这些和未来变化的更多信息可在 计划的破坏性变化 页面找到。
.skipTaskbarBrowserWindow constructor 选项 skipTaskbar 在 Linux 上不再支持。 在 #33226 中更改
半文档化的 preloadURL 属性已从 Web 首选项中删除。 #33228. 使用 WebPreferences.preload 代替。
Electron 14.x.y 和 15.x.y 都已终止支持。 该博客文章 使 Electron 恢复到其支持最新三个主要版本的 早期政策 。 鼓励开发人员和应用程序升级到较新版本的 Electron。
| E15 (9月21日) | E16 (11月21日) | E17 (2月22日) | E18 (3月22日) | E19 (5月22日) |
|---|---|---|---|---|
| 15.x.y | 16.x.y | 17.x.y | 18.x.y | 19.x.y |
| 14.x.y | 15.x.y | 16.x.y | 17.x.y | 18.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 | -- |
在短期内，您可以期望该团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium，Node 和 V8。 虽然我们谨慎地不对发布日期做出承诺，但我们的计划是大约每2个月发布一次带有新版本组件的主要版本的 Electron。
您可以在此处找到 Electron 的公开时间表。
有关这些和未来变化的更多信息可在 计划的破坏性变化 页面找到。
Electron is changing its primary S3 bucket, you may need to update your build scripts
A significant amount of Electron's build artifacts are uploaded to an S3 bucket called gh-contractor-zcbenz. As part of ongoing infrastructure/ownership migrations that started way back in 2020, we will be changing everything that used gh-contractor-zcbenz from its old home in S3 to a new storage system hosted at https://artifacts.electronjs.org. The path prefix that most of our assets use is changing slightly as well. Examples are included below:
Before: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib After: https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib
The important things here are the Hostname changed and the /atom-shell prefix changed. Another example, this time for debug symbols:
Before: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb After: https://artifacts.electronjs.org/symbols/path/to/symbol.pdb
Again, the hostname changed and the /atom-shell prefix was changed.
Anyone using standard build tooling such as electron-rebuild, electron-packager or @electron/get won't have to do anything. This should be the majority of people.
For anyone directly referencing the S3 bucket, you must update your reference to point at the hostname and update the path as well.
Most data that existed on the gh-contractor-zcbenz bucket has been cloned into the new storage system. This means all debug symbols and all headers have been copied. If you relied on some data in that bucket that hasn't been copied over please raise an issue in electron/electron and let us know.
The current gh-contractor-zcbenz S3 bucket will not be actively deleted. However, we can't guarantee how long that bucket will be left alive. We strongly recommend updating to target the new bucket as soon as possible.
Electron 18.0.0 已发布！ 它包括升级到 Chromium 100, V8 10.0, 和 Node.js 16.13.2。 请阅读下文了解更多详情！
Electron 团队很高兴发布了 Electron 18.0.0.0！ 您可以通过 npm install electron@latest 进行安装，或者从我们的 发布网站 下载它。 继续阅读有关此版本的详细信息，并请分享您的任何反馈！
从 Electron 15 开始，Electron 将每 8 周发布一个新的主要稳定版本。 您可以在此处阅读 完整详细信息。
此外，Electron 将会改变支持的版本，从最新的三个版本改为最新的四个版本，直到 2022 年 5 月。 关于 Electron 版本的更多详细信息，请看我们的 版本管理文档 2022 年 5 月以后，我们将回到支持最新的三个版本。
100
16.13.2
10.0ses.setCodeCachePath() API，用于设置代码缓存目录。 #33286BrowserWindowProxy 的 window.open 实现。 这也删除了 webPreferences 中的 nativeWindowOpen 选项。 #29405WebContents 中增加了 'focus' 和 'blur' 事件。 #25873showSubstitutions``toggleSmartQuotes``toggleSmartDashes``toggleTextReplacement #32024first-instance-ack event to the app.requestSingleInstanceLock() flow, allowing users to seamlessly transmit data from the first instance to the second instance. #31460setBackgroundColor 中增加了更多颜色的支持。 #33364有关新功能和变更的完整列表，请参阅 18.0.0 发布通知 。
以下是 Electron 18 中引入的突破性变化。 有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。
nativeWindowOpen在 Electron 15之前， window.open 默认使用 BrowserWindowProxy。 这意味着 window.open('about:blank') 无法打开可同步编写脚本的子窗口，以及有其他不兼容之处。 自 Electron 15 起, nativeWindowOpen 将默认启用。
有关更多详细信息，请参阅 Electron 中的 window.open 文档。 删除此功能的 PR: #29405
根据项目的支持政策，Electron 14.x.y 已经达到了支持的终点。 我们鼓励开发者和应用程序升级到更新的 Electron版本。
从 Electron 15 开始，我们已经将支持的版本从最新的三个版本改为最新的四个版本，直到 2022 年 5 月的 Electron 19。 在 Electron 19 之后，我们将回归到支持最新的三个版本。 此版本支持变化是我们新的节奏变化的一部分。 请参阅 我们的博客文章 ，了解的完整详细信息。
| E15 (9 月 21 号) | E16 (11 月 21 号) | E17 (2 月 22 号) | E18 (3 月 22 号) | E19 (5 月 22 号) |
|---|---|---|---|---|
| 15.x.y | 16.x.y | 17.x.y | 18.x.y | 19.x.y |
| 14.x.y | 15.x.y | 16.x.y | 17.x.y | 18.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 | -- |
在短期内，你可以期待我们的团队继续专注于跟上构成 Electron 的主要组件的发展，包括 Chromium、Node 和 V8。 尽管我们很谨慎，不对发布日期作出承诺，但我们的计划是大约每两个月发布一次 Electron 的主要版本和这些组件的新版本。
您可以在此处找到 Electron的公开时间表。
有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。
Electron 团队很高兴地宣布，今年我们将首次参加 Google 代码之夏（Summer of Code）！
Google Summer of Code（GSoC）是一项年度指导计划，将开源软件项目与潜在贡献者联系起来。 以前只对学生开放，任何18岁及以上的人现在都可以注册GSoC。
有关更多信息，请查看 Summer of Code 主页。
您有兴趣与Electron合作吗？ 如果您是新手或初学者开源贡献者，我们欢迎您申请！
为了被选为Google Summer of Code的电子贡献者，您需要提交申请。 申请将于2022年4月4日 开放，并于2022年4月19日结束。 您可以在此处关注 Google 代码之夏应用程序指南的更新。
想要申请吗？ 首先，查看我们准备的 五个项目创意草案 。 所有列出的想法目前都开放供提案。 我们也愿意接受不在拟议项目清单上的新想法。
您的申请应包括：
您还可以通读 官方 GSoC 学生/贡献者指南 ，了解有关准备提案的重要提示。
如果您想讨论项目提案或有疑问，请移步我们的 #gsoc-general Discord 频道！