今天上午在 OpenJS World 上，我们宣布 Electron 已正式从 OpenJS Foundation 的孵化计划中毕业，现在是 OpenJS Foundation Impact 项目。

Electron 于 2019 年 12 月在蒙特利尔举行的上一次 OpenJS Foundation 全球会议上进入孵化阶段。我们很高兴能够作为 Impact 项目在 JavaScript 社区中发挥更大的作用，并继续与 OpenJS Foundation 合作。

了解更多​

您可以在 OpenJSF 网站上阅读有关该基金会、其使命及其成员的信息。OpenJS Foundation 托管了许多开源 JavaScript 项目，包括 jQuery、Node.js 和 webpack。它得到了 30 个企业和最终用户成员的支持，包括 GoDaddy、Google、IBM、Intel、Joyent 和 Microsoft。

Electron 是一个用于使用 Web 技术构建跨平台桌面应用程序的开源框架。要了解有关 Electron 背后的开发人员以及他们如何协同工作的更多信息，请查看我们的 治理页面。

要开始使用 Electron 本身，请查看 我们的文档。

Electron 暂时暂停主要版本发布

发生了什么？​

我们的 主要版本发布节奏计划与 Chromium 的发布节奏保持一致，并且 Chromium 项目最近决定由于调整后的工作计划而 暂停其版本发布。这意味着在 Chromium 更改节奏的持续时间内，Electron 也将暂时暂停新的主要版本发布。

我们认为最好的选择是遵循 Chromium 的脚步，因此在此期间，Electron 团队将转向全职工作，专注于错误修复、安全性、性能和稳定性。

我们希望确保在此期间维护者和使用者的福祉都得到优先考虑，因此我们欢迎您的反馈，并期待恢复正常的发布计划。

有关更多更新，请关注我们的 Twitter 帐户。

编辑 (2020-03-30)：Electron 9 stable 将以 Chromium M83 为目标，并于 2020 年 5 月 19 日发布，以响应 Chromium 宣布跳过 M82 stable 日期并调整 M83 stable 日期。

在蒙特利尔举行的 Node+JS Interactive 上，OpenJS Foundation 宣布已接受 Electron 加入该基金会的孵化计划。该基金会致力于通过提供一个中立的组织来托管和维持项目，以及共同资助有益于整个社区的活动，从而支持 JavaScript 生态系统和 Web 技术的健康发展。

OpenJS Foundation 托管了许多开源 JavaScript 项目，包括 jQuery、Node.js 和 webpack。它得到了 30 个企业和最终用户成员的支持，包括 GoDaddy、Google、IBM、Intel、Joyent 和 Microsoft。Electron 是一个用于使用 Web 技术构建跨平台桌面应用程序的开源框架。

对于 Electron 来说，这是一个令人兴奋的举动，我们认为这是我们作为开源项目发展过程中的下一步。

这对开发人员意味着什么​

Electron 加入 OpenJS Foundation 不会改变 Electron 的制作、发布或使用方式，也不会直接影响使用 Electron 构建应用程序的开发人员。即使 Electron 最初于 2013 年在 GitHub 上创建，但目前它由许多组织和个人维护。2019 年，Electron 对其治理结构进行了编纂，并大力投资于正式化影响整个项目的决策方式。我们相信，多个组织和开发人员投资并协作开发 Electron 使该项目更强大。

将 Electron 从由单个公司实体拥有提升到专注于支持 Web 和 JavaScript 生态系统的中立基金会，这是我们作为开源项目成熟的自然下一步。

了解更多​

您可以在 OpenJSF 网站上阅读有关该基金会、其使命及其成员的信息。有关接受 Electron 进入 OpenJSF 孵化计划的更多信息和引言，请查看官方新闻稿。要了解有关 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 项目中的人员与世界各地时区的志愿者、全职维护人员以及所有依赖 Electron 的多家公司进行协调。到目前为止，我们在非正式协调方面取得了成功；但是，随着团队的壮大，我们发现这种方法无法扩展。我们还希望使新的贡献者更容易找到在项目中安家的地方。

工作组​

Electron 治理包括负责项目不同部分的工作组。我们从七个小组开始

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

这些小组将相互协调，但每个小组都有自己的会议安排和议程，以便自行高效工作。有关这些小组的更多详细信息，请参见 治理存储库。

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

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

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

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

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

Electron 究竟不再支持什么？​

您可能在您的电脑上看到过 "64 位" 和 "32 位" 的标签，或者作为下载软件的选项。 这个术语用于描述特定的计算机架构。 20 世纪 90 年代和 21 世纪初生产的大多数电脑都使用基于 32 位架构的 CPU，而之后生产的大多数电脑都使用更新、更强大的 64 位架构。 Nintendo 64（明白了吗？）和 PlayStation 2 是首批广泛使用的采用新架构的消费设备，2010 年后销售的电脑几乎全部包含 64 位处理器。 因此，支持一直在萎缩：Google 于 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 3 将支持 32 位 Linux，直到 Electron 6 发布，这为您做出决定和计划提供了一些时间。

这对用户意味着什么？​

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

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

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

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

2014 年，V8 团队弃用了 v8::Handle，转而使用 v8::Local 作为局部句柄。 Electron 5.0 包含一个 V8 版本，该版本最终永久删除了 v8::Handle，并且仍然使用它的原生 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 现在使用 GN 构建自身。 这是关于为什么的讨论。

GYP 和 GN

当 Electron 于 2013 年首次发布时，Chromium 的构建配置是用 GYP 编写的，GYP 是 "Generate Your Projects" 的缩写。

2014 年，Chromium 项目引入了一个新的构建配置工具，称为 GN（"Generate Ninja" 的缩写）。 Chromium 的构建文件已迁移到 GN，GYP 已从源代码中删除。

历史上，Electron 一直在主要的 Electron 代码和 libchromiumcontent 之间保持分离，后者是 Electron 中包装 Chromium 的 'content' 子模块的部分。 Electron 继续使用 GYP，而 libchromiumcontent 作为 Chromium 的一个子集，在 Chromium 这样做时切换到了 GN。

就像不太啮合的齿轮一样，使用这两个构建系统之间存在摩擦。 维护兼容性容易出错，编译器标志和 #defines 需要在 Chromium、Node、V8 和 Electron 之间小心翼翼地保持同步。

为了解决这个问题，Electron 团队一直在努力将所有内容迁移到 GN。 今天，从 Electron 中删除最后一个 GYP 代码的 提交已在 master 中落地。

这对你意味着什么

如果您正在为 Electron 本身做出贡献，那么从 master 或 4.0.0 中检出和构建 Electron 的过程与 3.0.0 及更早版本中的过程截然不同。 有关详细信息，请参阅 GN 构建说明。

如果您正在使用 Electron 开发应用程序，您可能会在新的 Electron 4.0.0-nightly 中注意到一些小的更改； 但更有可能的是，Electron 构建系统的更改对您来说将是完全透明的。

这对 Electron 意味着什么

GN 比 GYP 更快，并且它的文件更易于阅读和维护。 此外，我们希望使用单个构建配置系统可以减少将 Electron 升级到新版本的 Chromium 所需的工作。

• 由于 Chromium 67 取消了对 MSVC 的支持并切换到在 Windows 上使用 Clang 构建，因此它已经极大地帮助了 Electron 4.0.0 的开发。 使用 GN 构建，我们可以直接从 Chromium 继承所有编译器命令，因此我们免费获得了 Windows 上的 Clang 构建！

• 它还使 Electron 更容易在 Electron、Chromium 和 Node 中使用统一构建中的 BoringSSL，这在之前是 有问题的。

Electron 1.4.12 包含一个重要的补丁，该补丁修复了一个上游 Chrome 问题，该问题导致某些 Symantec、GeoTrust 和 Thawte SSL/TLS 证书在 libchromiumcontent（Electron 的底层 Chrome 库）的构建时间后的 10 周内被错误地拒绝。 受影响站点上使用的证书没有问题，更换这些证书也无济于事。

在 Electron 1.4.0 — 1.4.11 中，在特定日期之后，使用这些受影响的证书的站点的 HTTPS 请求将因网络错误而失败。 这会影响使用 Chrome 的底层网络 API 发出的 HTTPS 请求，例如 window.fetch、Ajax 请求、Electron 的 net API、BrowserWindow.loadURL、webContents.loadURL、<webview> 标记上的 src 属性等等。

将您的应用程序升级到 1.4.12 将防止这些请求失败的发生。

注意：此问题是在 Chrome 53 中引入的，因此早于 1.4.0 的 Electron 版本不受影响。

影响日期​

下面是每个 Electron 1.4 版本的表格，以及使用这些受影响的证书的站点的请求将开始失败的日期。

您可以通过提前设置计算机的时钟来验证应用程序的影响日期，然后检查是否可以从中成功加载 https://symbeta.symantec.com/welcome/。

更多信息​

您可以在以下位置阅读有关此主题、原始问题和修复程序的更多信息

• 什么是证书透明度？
• Symtantec 知识库文章
• Chrome issue 664177
• Chrome 对 issue 664177 的修复
• libchromiumcontent 对 issue 664177 的补丁

从 Electron 1.3.1 版本开始，您可以 npm install electron --save-dev 以在您的应用程序中安装 Electron 的最新预编译版本。

预构建的 Electron 二进制文件​

如果您以前开发过 Electron 应用程序，您可能遇到过 electron-prebuilt npm 包。 这个包几乎是每个 Electron 项目不可或缺的一部分。 安装后，它会检测您的操作系统并下载一个预构建的二进制文件，该文件经过编译可在您系统的架构上运行。

新名称​

Electron 安装过程通常是新开发人员的绊脚石。 许多勇敢的人尝试通过运行 npm install electron 而不是 npm install electron-prebuilt 来开始开发 Electron 应用程序，结果却发现（通常是在迷惑不解之后）这不是他们要寻找的 electron。

这是因为 npm 上存在一个现有的 electron 项目，该项目是在 GitHub 的 Electron 项目存在之前创建的。 为了使 Electron 开发对新开发人员来说更容易和更直观，我们联系了现有 electron npm 包的所有者，询问他是否愿意让我们使用该名称。 幸运的是，他是我们项目的粉丝，并同意帮助我们重新利用该名称。

Prebuilt 继续存在​

从 1.3.1 版本开始，我们已开始同时将 electron 和 electron-prebuilt 包发布到 npm。 这两个包是相同的。 我们选择在一段时间内继续以两个名称发布该包，以免给目前在其项目中使用 electron-prebuilt 的数千名开发人员带来不便。 我们建议更新您的 package.json 文件以使用新的 electron 依赖项，但我们将继续发布 electron-prebuilt 的新版本，直到 2016 年底。

electron-userland/electron-prebuilt 存储库将仍然是 electron npm 包的规范主页。

非常感谢​

我们特别感谢 @mafintosh、@maxogden 和许多其他 贡献者创建和维护 electron-prebuilt，以及他们为 JavaScript、Node.js 和 Electron 社区提供的不知疲倦的服务。

并感谢 @logicalparadox 允许我们接管 npm 上的 electron 包。

更新您的项目​

我们已经与社区合作更新了受此更改影响的流行包。 像 electron-packager、electron-rebuild 和 electron-builder 这样的包已经更新为可以使用新名称，同时继续支持旧名称。

如果您在安装这个新包时遇到任何问题，请通过在 electron-userland/electron-prebuilt 存储库上打开一个 issue 来告诉我们。

对于 Electron 的任何其他问题，请使用 electron/electron 存储库。