Electron 团队很高兴宣布发布 Electron 6.0.0！您可以通过 npm 使用 npm install electron@latest 安装它，或者从我们的发布网站下载。这个版本包含了升级、修复和新功能。我们迫不及待地想看到您用它们构建的应用！请继续阅读有关此版本的详情，并请分享您的任何反馈！

新特性​

今天标志着 Electron 项目的一个创举：这是我们第一次在与相应的 Chrome 稳定版 同一天 发布 Electron 稳定版！🎉

Electron 的大部分功能由 Chromium、Node.js 和 V8 等核心组件提供。Electron 与这些项目保持同步更新，以便为用户提供新的 JavaScript 特性、性能改进和安全修复。在 Electron 6 中，这些软件包的每个主版本都得到了更新

• Chromium 76.0.3809.88
  • 74 中的新特性
  • 75 中的新特性
  • 76 中的新特性
• Node.js 12.4.0
  • Node 12.4.0 博客文章
• V8 7.6.303.22
  • V8 7.6 博客文章

本次发布还包含了对 Electron API 的改进。发布说明中有更完整的列表，以下是亮点部分：

Promise 化​

Electron 6.0 继续了在 5.0 中启动的现代化倡议，以改进 Promise 支持。

这些函数现在返回 Promise，并且仍然支持旧的基于回调的调用方法：

• contentTracing.getCategories() #16583
• contentTracing.getCategories() #16583
• contentTracing.getTraceBufferUsage() #16600
• contents.executeJavaScript() #17312
• cookies.flushStore() #16464
• cookies.get() #16464
• cookies.remove() #16464
• cookies.set() #16464
• dialog.showCertificateTrustDialog() #17181
• inAppPurchase.getProducts() #17355
• inAppPurchase.purchaseProduct()#17355
• netLog.stopLogging() #16862
• session.clearAuthCache() #17259
• session.clearCache() #17185
• session.clearHostResolverCache() #17229
• session.clearStorageData() #17249
• session.getBlobData() #17303
• session.getCacheSize() #17185
• session.resolveProxy() #17222
• session.setProxy() #17222
• webContents.hasServiceWorker() #16535
• webContents.printToPDF() #16795
• webContents.savePage() #16742
• webFrame.executeJavaScript() #17312
• webFrame.executeJavaScriptInIsolatedWorld() #17312
• webviewTag.executeJavaScript() #17312

这些函数现在有两种形式：同步和基于 Promise 的异步：

• dialog.showMessageBox()/dialog.showMessageBoxSync() #17298
• dialog.showOpenDialog()/dialog.showOpenDialogSync() #16973
• dialog.showSaveDialog()/dialog.showSaveDialogSync() #17054

这些函数现在返回 Promise：

• app.dock.show() #16904

Electron Helper (Renderer).app、Electron Helper (GPU).app 和 Electron Helper (Plugin).app​

为了启用加固运行时，它会限制可写可执行内存和加载由不同团队 ID 签名的代码等内容，需要向 Helper 授予特殊的代码签名权限。

为了将这些权限限定在需要它们的进程类型范围内，Chromium 添加了 Helper 应用的三个新变体：一个用于渲染器 (Electron Helper (Renderer).app)，一个用于 GPU 进程 (Electron Helper (GPU).app)，一个用于插件 (Electron Helper (Plugin).app)。

使用 electron-osx-sign 对 Electron 应用进行代码签名的用户无需更改其构建逻辑。如果您使用自定义脚本对应用进行代码签名，应确保正确地对这三个新的 Helper 应用进行代码签名。

为了正确地使用这些新的 Helper 打包您的应用，您需要使用 electron-packager@14.0.4 或更高版本。如果您正在使用 electron-builder，您应该关注此议题以跟踪对这些新 Helper 的支持。

重大变更​

• 本次发布开始为未来的一个要求奠定基础，即在渲染器进程中加载的 Node 原生模块必须是 N-API 或 上下文感知（Context Aware）的。做出此更改的原因是为了更快的性能、更强的安全性和减少维护工作量。请阅读此议题中的完整详情，包括提议的时间表。此更改预计在 Electron v11 中完成。

• net.IncomingMessage 的头部已略有变化，以便更接近 Node.js 的行为，特别是关于 set-cookie 的值以及如何处理重复的头部。#17517。

• shell.showItemInFolder() 现在返回 void 且是一个异步调用。#17121

• 现在，应用必须在使用 app.getPath('log') 之前调用新的函数 app.setAppLogPath() 来显式设置日志路径。#17841

停止支持 3.x.y​

根据我们的支持政策，3.x.y 已达到生命周期终止。鼓励开发者和应用程序升级到较新版本的 Electron。

应用反馈计划​

我们继续使用我们的应用反馈计划进行测试。参与此计划的项目会在其应用上测试 Electron Beta 版本；作为回报，他们发现的新错误将优先在新稳定版中修复。如果您想参与或了解更多信息，请查看我们关于此计划的博客文章。

下一步计划​

短期内，您可以期待团队继续专注于跟进构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。尽管我们谨慎地不承诺发布日期，但我们的计划是大约每季度发布带有这些新组件版本的新 Electron 主要版本。暂定的 7.0.0 时间表列出了 Electron 7 开发生命周期中的关键日期。另外，请参阅我们的版本控制文档，以获取关于 Electron 版本控制的更详细信息。

有关即将发布的 Electron 版本中的计划重大变更的信息，请参阅我们的计划重大变更文档。

🎉 Electron 将改为每 12 周发布一个新的主要稳定版本！🎉

⚡️ 哇，真快！但为什么呢？​

简单地说，Chromium 没有停止发布，所以 Electron 也不会放慢速度。

Chromium 按照固定的 6 周时间表发布。为了在 Electron 中提供最新的 Chromium 版本，我们的时间表需要跟进他们。有关 Chromium 发布周期的更多信息可以在这里找到。

🚀 为什么是每 12 周？​

每隔 6 周，都会发布一个新的 Chromium 版本，其中包含新特性、错误修复/安全修复以及 V8 的改进。Electron 的用户明确表示希望及时获得这些更改，因此我们调整了稳定版发布日期，以便与每隔一次的 Chromium 稳定版发布同步。首先，Electron v6.0.0 将包含 M76，计划于 2019 年 7 月 30 日 发布稳定版，这与 Chromium M76 的发布日期相同。

🚧 这对我我和我的 Electron 应用意味着什么？​

您将比以前更快地获得新的 Chromium 和 V8 特性及修复。更重要的是，您也将知道这些新变化何时到来，因此您可以比以前更好地进行规划。

Electron 团队将继续支持最新的三个主要版本。例如，当 v6.0.0 于 2019 年 7 月 30 日发布稳定版时，我们将支持 v6.x、v5.x 和 v4.x，而 v3.x 将达到生命周期终止。

💬 应用反馈计划​

请考虑加入我们的应用反馈计划，帮助我们测试 Beta 版本并进行稳定化。参与此计划的项目会在其应用上测试 Electron Beta 版本；作为回报，他们发现的新错误将优先在新稳定版中修复。

📝 Electron 发布简史​

v3.0.0 之前稳定版发布的决定没有遵循时间表。我们在 v3.0.0 和 v4.0.0 中为项目添加了内部时间表。今年早些时候，我们决定首次公布 Electron v5.0.0 的稳定版发布日期。公布稳定版发布日期总体上受到了积极的欢迎，我们也很高兴在未来的版本中继续这样做。

为了更好地简化这些与升级相关的工作，我们在治理体系内创建了升级和发布工作组。这使得我们能够更好地确定这项工作的优先级并进行委派，我们希望随着后续每个版本的发布，这一点会变得更加明显。

以下是我们新节奏与 Chromium 节奏的对比：

📨 如果您有问题，请发送电子邮件至 info@electronjs.org 与我们联系。

Electron 团队很高兴宣布发布 Electron 5.0.0！您可以通过 npm 使用 npm install electron@latest 安装它，或者从我们的发布页面下载 tarball。此版本包含升级、修复和新功能。我们迫不及待地想看到您用它们构建的应用！请继续阅读有关此版本的详情，并请分享您的任何反馈！

新特性？​

Electron 的大部分功能由 Chromium、Node.js 和 V8 等核心组件提供。Electron 与这些项目保持同步更新，以便为用户提供新的 JavaScript 特性、性能改进和安全修复。在 Electron 5 中，这些软件包的每个主版本都得到了更新：

• Chromium 73.0.3683.119
  • 70 中的新特性
  • 71 中的新特性
  • 72 中的新特性
  • 73 中的新特性
• Node.js 12.0.0
  • Node 12 博客文章
• V8 7.3.492.27。
  • 新的 JS 特性

Electron 5 还包含对 Electron 特有 API 的改进。主要变更摘要如下；有关完整变更列表，请查看 Electron v5.0.0 发布说明。

Promise 化​

Electron 5 继续推行 Promisification 计划，将 Electron 基于回调的 API 转换为使用 Promise。以下 API 已转换为 Promise：

• app.getFileIcon
• contentTracing.getCategories
• contentTracing.startRecording
• contentTracing.stopRecording
• debugger.sendCommand
• Cookies API
• shell.openExternal
• webContents.loadFile
• webContents.loadURL
• webContents.zoomLevel
• webContents.zoomFactor
• win.capturePage

macOS 系统颜色访问​

以下函数已更改或添加到 systemPreferences 以访问 macOS 系统颜色：

• systemPreferences.getAccentColor
• systemPreferences.getColor
• systemPreferences.getSystemColor

进程内存信息​

已添加函数 process.getProcessMemoryInfo，用于获取当前进程的内存使用统计信息。

remote API 的额外过滤​

为了改进 remote API 的安全性，添加了新的 remote 事件，以便对 remote.getBuiltin、remote.getCurrentWindow、remote.getCurrentWebContents 和 <webview>.getWebContents 进行过滤。

BrowserWindow 支持多个 BrowserViews​

BrowserWindow 现在支持在同一个 BrowserWindow 中管理多个 BrowserViews。

重大变更​

打包应用的默认行为​

打包应用现在的行为将与默认应用相同：除非应用已有一个菜单，否则会创建一个默认的应用菜单；除非应用自己处理 window-all-closed 事件，否则该事件将自动处理。

混合沙盒模式​

混合沙盒模式现在默认启用。使用 sandbox: true 启动的渲染器现在将真正地进行沙盒化，而以前只有在混合沙盒模式也启用时才会进行沙盒化。

安全改进​

nodeIntegration 和 webviewTag 的默认值现在已设为 false，以提高安全性。

拼写检查器现在支持异步​

SpellCheck API 已更改为提供异步结果。

弃用​

以下 API 在 Electron 5.0.0 中新近弃用，并计划在 6.0.0 中移除：

用于 arm 和 arm64 的 Mksnapshot 二进制文件​

用于 arm 和 arm64 的 mksnapshot 原生二进制文件已弃用，并将在 6.0.0 中移除。可以使用 x64 二进制文件为 arm 和 arm64 创建快照。

WebContents 上的 ServiceWorker API​

已弃用 WebContents 上的 ServiceWorker API，为将其移除做准备。

• webContents.hasServiceWorker
• webContents.unregisterServiceWorker

沙盒化 webContents 中的自动模块​

为了提高安全性，以下模块已弃用通过 require 直接使用，而需要在沙盒化的 webcontents 中通过 remote.require 引入：

• electron.screen
• child_process
• fs
• os
• path

webFrame Isolated World API​

webFrame.setIsolatedWorldContentSecurityPolicy、webFrame.setIsolatedWorldHumanReadableName、webFrame.setIsolatedWorldSecurityOrigin 已弃用，推荐使用 webFrame.setIsolatedWorldInfo。

混合沙盒模式​

enableMixedSandbox 和 --enable-mixed-sandbox 命令行开关出于兼容性目的仍然存在，但已弃用且无效。

停止支持 2.0.x​

根据我们的支持版本政策，2.0.x 已达到生命周期终止。

应用反馈计划​

我们继续使用我们的应用反馈计划进行测试。参与此计划的项目会在其应用上测试 Electron Beta 版本；作为回报，他们发现的新错误将优先在新稳定版中修复。如果您想参与或了解更多信息，请查看我们关于此计划的博客文章。

下一步计划​

短期内，您可以期望团队继续专注于紧跟构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。虽然我们谨慎地不对发布日期做出承诺，但我们的计划是大约每季度发布 Electron 的新主要版本以及这些组件的新版本。暂定的 6.0.0 发布计划列出了 Electron 6 开发生命周期中的关键日期。此外，请参阅我们的版本控制文档，了解有关 Electron 中版本控制的更详细信息。

有关即将发布的 Electron 版本中的计划重大变更的信息，请参阅我们的计划重大变更文档。

Electron 中用 C++ 或 Objective-C 编写的功能如何到达 JavaScript，以便最终用户可以使用它们？

背景​

Electron 是一个 JavaScript 平台，其主要目的是降低开发者构建强大的桌面应用程序的门槛，而无需担心平台特定的实现。然而，在其核心，Electron 本身仍然需要使用给定系统语言编写平台特定的功能。

实际上，Electron 会为您处理原生代码，以便您可以专注于单一的 JavaScript API。

然而，这是如何工作的呢？Electron 中用 C++ 或 Objective-C 编写的功能如何到达 JavaScript，以便最终用户可以使用它们？

要追溯这条路径，让我们从 app 模块开始。

通过打开 lib/ 目录下的 app.ts 文件，您会发现顶部有以下代码行

const binding = process.electronBinding('app');

这行代码直接指向了 Electron 将其 C++/Objective-C 模块绑定到 JavaScript 供开发者使用的机制。这个函数由 ElectronBindings 类的头文件和实现文件创建。

process.electronBinding​

这些文件添加了 process.electronBinding 函数，其行为类似于 Node.js 的 process.binding。process.binding 是 Node.js require() 方法的低层实现，不同之处在于它允许用户 require 原生代码而不是用 JS 编写的其他代码。这个自定义的 process.electronBinding 函数赋予了从 Electron 加载原生代码的能力。

当一个顶层 JavaScript 模块（如 app）需要这个原生代码时，该原生代码的状态是如何确定和设置的？哪些方法暴露给了 JavaScript？属性呢？

native_mate​

目前，这个问题的答案可以在 native_mate 中找到：它是 Chromium 的 gin 库的一个分支，它使得在 C++ 和 JavaScript 之间处理类型更加容易。

在 native_mate/native_mate 中，有一个用于 object_template_builder 的头文件和实现文件。这使我们能够在原生代码中形成符合 JavaScript 开发者期望的模块结构。

mate::ObjectTemplateBuilder​

如果我们将每个 Electron 模块都视为一个 object，那么我们为什么要使用 object_template_builder 来构建它们就变得更容易理解了。这个类构建在 V8 暴露的类之上，V8 是谷歌的开源高性能 JavaScript 和 WebAssembly 引擎，用 C++ 编写。V8 实现了 JavaScript (ECMAScript) 规范，因此它的原生功能实现可以直接与 JavaScript 中的实现相关联。例如，v8::ObjectTemplate 为我们提供了没有专门构造函数和原型的 JavaScript 对象。它使用 Object[.prototype]，在 JavaScript 中相当于 Object.create()。

要看这个在实际中的应用，请查看 app 模块的实现文件 atom_api_app.cc。在文件的底部有以下内容

mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
    .SetMethod("getGPUInfo", &App::GetGPUInfo)

在上面的行中，.SetMethod 在 mate::ObjectTemplateBuilder 上被调用。.SetMethod 可以对 ObjectTemplateBuilder 类的任何实例调用，以便在 JavaScript 中的对象原型（Object prototype）上设置方法，语法如下：

.SetMethod("method_name", &function_to_bind)

这相当于 JavaScript 中的：

function App{}
App.prototype.getGPUInfo = function () {
  // implementation here
}

这个类还包含在模块上设置属性的函数：

.SetProperty("property_name", &getter_function_to_bind)

或

.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)

这些反过来就是 Object.defineProperty 在 JavaScript 中的实现：

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
})

和

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
  set(newPropertyValue) {
    _myProperty = newPropertyValue
  }
})

这样就可以创建开发者期望的带有原型和属性的 JavaScript 对象，并且更清晰地理解在较低系统级别实现函数和属性！

关于在哪里实现任何给定的模块方法的决定本身就是一个复杂且通常非确定性的问题，我们将在未来的文章中介绍。

随着 Electron 在桌面应用程序中的流行度日益增长，其团队也随之壮大：我们有更多为不同公司工作、生活在不同时区、兴趣各异的全职维护者。我们正在引入一种治理结构，以便能够平稳地持续发展。

为什么事情在改变？​

Electron 项目的成员与全球不同时区的志愿者、全职维护者以及依赖 Electron 的多家公司进行协调。在此之前，我们通过非正式协调取得了成功；但随着团队的壮大，我们发现这种方法无法扩展。我们还希望让新的贡献者更容易在项目中找到归属感。

工作组​

Electron 治理结构包括负责项目不同部分的工作组。我们最初设立了七个工作组：

• 社区与安全：处理 行为准则（Code of Conduct） 问题。
• 文档与工具：负责外部工具（例如 Fiddle、Forge）和 Electron 文档。
• 推广：帮助壮大 Electron 社区。
• 发布：确保发布版本稳定并按计划进行。
• 安全：执行安全测试并响应安全问题。
• 升级：集成上游升级，例如 V8、Chromium 和 Node 的新版本。
• 网站：维护和改进 Electron 网站。

这些工作组将相互协调，但每个工作组都有自己的会议日程和议程，以便独立高效地工作。有关这些工作组的更多详细信息，请参见治理仓库。

这会改变 Electron 项目的方向吗？​

这对 Electron 的方向不应产生任何直接影响。如果我们的策略成功，工作组将使新贡献者更容易找到他们感兴趣的主题，并通过将与维护者日常工作无关的讨论转移到其他组，简化维护者的工作。如果发生这种情况，可能会通过让更多没有障碍的人一起工作来间接影响事物。

我在哪里可以了解更多信息？​

• 治理仓库和章程提供了关于新治理结构的信息。
• 每个工作组都有自己的页面：社区、文档与工具、推广、发布、安全、升级和网站。
• 您可以通过提交一个 issue 或发送邮件至 info@electronjs.org 联系维护者。

在 Chrome 中发现了一个高危漏洞，该漏洞影响所有基于 Chromium 的软件，包括 Electron。

该漏洞已被分配 CVE-2019-5786。您可以在 Chrome 博客文章中阅读更多相关信息。

请注意，Chrome 报告称该漏洞已在野外被利用，因此强烈建议您尽快升级 Electron。

范围​

这会影响任何可能运行第三方或不受信任 JavaScript 的 Electron 应用程序。

缓解措施​

受影响的应用程序应升级到已打补丁的 Electron 版本。

我们已经发布了包含此漏洞修复的新版本 Electron：

• 4.0.8
• 3.1.6
• 3.0.16
• 2.0.18

Electron 5 的最新 Beta 版本跟踪了 Chromium 73，因此已经打上了补丁。

• 5.0.0-beta.5

更多信息​

此漏洞由 Google 威胁分析小组的 Clement Lecigne 发现并报告给 Chrome 团队。Chrome 博客文章可在此处找到。

要了解有关确保 Electron 应用程序安全最佳实践的更多信息，请参阅我们的安全教程。

如果您希望报告 Electron 中的漏洞，请发送电子邮件至 security@electronjs.org。

从 Electron v4.0 开始，Electron 团队将停止对 32 位 Linux (ia32 / i386) 的支持。最后一个支持 32 位 Linux 安装的 Electron 版本是 Electron v3.1，该版本将获得支持发布，直到 Electron v6 发布。对 64 位 Linux 和 armv7l 的支持将保持不变。

Electron 具体不再支持什么？​

您可能已经在电脑标签上或下载软件时看到过“64 位”和“32 位”的描述。这个术语用来描述特定的计算机体系结构。20世纪90年代和21世纪初的大多数计算机都使用了基于32位体系结构的 CPU，而稍后制造的大多数计算机都基于更新更强大的64位体系结构。Nintendo 64（明白了吗？）和 PlayStation 2 是首批广泛上市的使用新体系结构的消费设备，2010年后销售的计算机几乎都只包含64位处理器。因此，支持一直在缩减：谷歌在2016年3月停止发布32位 Linux 版 Chrome，Canonical 在2017年停止提供32位桌面镜像，并在 Ubuntu 18.10 中完全放弃了对32位的支持。Arch Linux、elementary OS 和其他著名的 Linux 发行版已经放弃了对老旧处理器体系结构的支持。

截至目前，Electron 一直提供并支持在旧的 32 位体系结构上运行的构建版本。从 v4.0 版本开始，Electron 团队将不再提供或支持 32 位 Linux 的二进制文件。

Electron 一直是一个充满活力的开源项目，我们继续支持并鼓励有兴趣为特殊体系结构构建 Electron 的开发者。

这对开发者意味着什么？​

如果您目前没有为 Linux 提供应用程序的 32 位分发版本，则无需采取任何行动。

发布 32 位 Linux Electron 应用程序的项目需要决定如何继续。在 Electron 6 发布之前，Electron 3 将支持 32 位 Linux，这为做出决定和计划提供了一些时间。

这对用户意味着什么？​

如果您是 Linux 用户，并且不确定您是否正在运行 64 位系统，您很可能正在 64 位架构上运行。要确定，您可以在终端中运行 lscpu 或 uname -m 命令。任何一个命令都会打印出您当前的架构。

如果您在 32 位处理器上使用 Linux，您可能已经遇到了难以找到近期发布的软件的问题。Electron 团队与其他重要的 Linux 社区成员一起，建议您升级到 64 位架构。

发现了一个代码漏洞，该漏洞允许在子窗口中重新启用 Node。

使用 sandbox: true 或 nativeWindowOpen: true 并带有 nodeIntegration: false 打开一个 BrowserView 会导致一个 webContents，在该 webContents 中可以调用 window.open，并且新打开的子窗口将启用 nodeIntegration。此漏洞影响所有受支持的 Electron 版本。

缓解措施​

我们已发布包含此漏洞修复的新版本 Electron：2.0.17、3.0.15、3.1.3、4.0.4 和 5.0.0-beta.2。我们鼓励所有 Electron 开发者立即将他们的应用程序更新到最新的稳定版本。

如果由于某些原因您无法升级 Electron 版本，可以通过禁用所有子 web 内容来缓解此问题：

view.webContents.on('-add-new-contents', (e) => e.preventDefault());

更多信息​

此漏洞由 PalmerAL 负责任地发现并报告给 Electron 项目。

要了解有关确保 Electron 应用程序安全最佳实践的更多信息，请参阅我们的安全教程。

如果您希望报告 Electron 中的漏洞，请发送电子邮件至 security@electronjs.org。

如果您在使用 Electron 5.0 时遇到原生 Node.js 插件的问题，可能是因为它需要更新以与最新版本的 V8 一起工作。

再见 v8::Handle，你好 v8::Local​

在 2014 年，V8 团队弃用了 v8::Handle，转而使用 v8::Local 来表示本地句柄。Electron 5.0 包含一个最终彻底移除了 v8::Handle 的 V8 版本，仍然使用它的原生 Node.js 插件需要更新后才能与 Electron 5.0 一起使用。

所需的代码更改是微小的，但是**每个**仍然使用 v8::Handle 的原生 Node 模块将无法与 Electron 5.0 一起构建，并且需要修改。好消息是 Node.js v12 也将包含此 V8 更改，因此任何使用 v8::Handle 的模块无论如何都需要更新才能与即将推出的 Node 版本一起工作。

我维护一个原生插件，如何提供帮助？​

如果您是 Node.js 的原生插件维护者，请确保将所有出现的 v8::Handle 替换为 v8::Local。前者只是后者的别名，因此无需进行其他更改来解决此特定问题。

您可能也有兴趣了解 N-API，它独立于 V8 作为 Node.js 本身的一部分进行维护，旨在隔离原生插件与底层 JavaScript 引擎的变化。您可以在 Node.js 网站上的 N-API 文档中找到更多信息。

救命！我的应用程序使用了原生插件，但它无法工作！​

如果您的应用程序使用了 Node.js 的原生插件，并且该插件由于此问题无法构建，请联系插件作者，查看他们是否发布了修复此问题的新版本。如果没有，联系作者（或提交 Pull Request！）可能是您最好的选择。

Electron 首次激动地公布我们的发布计划，从 v5.0.0 开始。这是我们拥有公开长期时间表的第一步。

正如我们在 v4.0.0 稳定版发布博客文章中提到的，我们计划大约每季度发布一次，以与 Chromium 的发布保持更紧密的节奏。Chromium 发布新版本的速度非常快——每 6 周一次。

看看 Electron 与 Chromium 的并行进展情况：

在 2018 年下半年，我们的首要任务是加快发布速度并更接近 Chromium。我们通过遵循预定的时间表成功做到了这一点。Electron 3.0.0 和 4.0.0 的发布间隔约为 2-3 个月。我们对在发布 5.0.0 及更高版本时保持这一速度持乐观态度。大约每季度发布一个主要 Electron 版本，我们现在与 Chromium 的发布节奏保持同步。领先于 Chromium 的稳定版本始终是我们的目标，我们正在为此努力。

我们很想承诺未来的日期，就像 Node.js 和 Chromium 那样，但我们**目前**还没有达到那个程度。我们乐观地认为未来将达到一个长期的时间表。

考虑到这一点，我们正在迈出第一步，公开 v5.0.0 的发布计划。您可以在此处找到它。

为了帮助我们测试 Beta 版本和进行稳定化，请考虑加入我们的应用程序反馈计划。