在今天早上的 OpenJS World 大会上，我们宣布 Electron 已正式从OpenJS Foundation 的孵化项目毕业，现已成为 OpenJS Foundation 的影响力项目（Impact Project）。

Electron 于 2019 年 12 月进入孵化阶段，当时在蒙特利尔举办了上一届 OpenJS Foundation 全球大会。作为影响力项目，我们很高兴能在 JavaScript 社区中扮演更重要的角色，并继续与 OpenJS Foundation 保持合作关系。

了解更多信息​

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

Electron 是一个开源框架，用于使用 Web 技术构建跨平台桌面应用。要详细了解 Electron 背后的团队以及他们如何协同工作，请查看我们的治理页面。

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

Electron 暂时暂停主要版本发布

发生了什么？​

我们的主要版本发布节奏与 Chromium 同步，而 Chromium 项目最近决定由于工作日程调整而暂停其版本发布。这意味着在 Chromium 调整发布节奏期间，Electron 也将暂时暂停新的主要版本发布。

我们认为最佳选择是遵循 Chromium 的做法，因此在此期间，Electron 团队将转为全力进行 bug 修复、安全、性能和稳定性的工作。

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

要获取更多更新，请关注我们的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。它得到了包括 GoDaddy、Google、IBM、Intel、Joyent 和 Microsoft 在内的 30 个企业和最终用户成员的支持。Electron 是一个开源框架，用于使用 Web 技术构建跨平台桌面应用。

这对 Electron 来说是令人兴奋的一步，我们将其视为我们作为开源项目发展演变的下一步。

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

Electron 加入 OpenJS Foundation 并不会改变 Electron 的构建、发布或使用方式——也不会直接影响使用 Electron 构建应用的开发者。尽管 Electron 最初于 2013 年在 GitHub 创建，但目前它由多个组织和个人维护。2019 年，Electron 制定了其治理结构（governance structure），并投入大量精力来规范影响整个项目的决策过程。我们相信，由多个组织和开发者共同投入和协作，将使项目更加强大。

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

了解更多信息​

您可以在 OpenJSF 网站上了解关于基金会、其使命及其成员的信息。要获取更多关于 Electron 被接受加入 OpenJSF 孵化项目的详情和引述，请查看官方新闻稿。要详细了解 Electron 背后的团队以及他们如何协同工作，请查看我们的治理页面。

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

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

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

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

Chromium 按固定的 6 周时间表发布。为了在 Electron 中提供最新的 Chromium 版本，我们的时间表需要跟随他们的。有关 Chromium 发布周期的更多信息，请在此处查看。

🚀 为什么是每 12 周？​

每 6 周，都会发布一个新的 Chromium 版本，其中包含新功能、bug 修复/安全修复和 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 将达到生命周期结束（End-Of-Life）。

💬 应用反馈计划​

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

📝 Electron 版本发布简史​

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

为了更好地精简这些与升级相关的工作，我们在治理体系内创建了升级和发布工作组（Working Groups）。它们使我们能够更好地确定此工作的优先级和分配任务，我们希望在后续的每个版本中都能看到这一点变得更加明显。

这是我们的新节奏与 Chromium 节奏的对比情况

📨 如果您有问题，请发送邮件至 info@electronjs.org。

随着 Electron 在桌面应用领域越来越受欢迎，其开发团队也在壮大：我们有更多全职维护者，他们来自不同的公司，生活在不同的时区，兴趣也各不相同。我们正在引入一种治理结构（governance structure），以便能够顺利地持续发展。

为什么会发生变化？​

Electron 项目的参与者来自世界各地的不同时区，他们包括志愿者、全职维护者以及依赖 Electron 的多家公司的员工。到目前为止，我们通过非正式协调取得了成功；但随着团队的壮大，我们发现这种方法无法扩展。我们还希望让新的贡献者更容易找到他们在项目中的位置。

工作组（Working Groups）​

Electron 的治理结构包括负责项目不同部分的工作组（Working Groups）。我们首先设立了七个组：

• 社区与安全：负责处理行为准则问题。
• 文档与工具：负责外部工具（例如 Fiddle、Forge）和 Electron 文档的管理。
• 外展：协助拓展 Electron 社区。
• 发布：确保版本发布稳定并按时进行。
• 安全：执行安全测试并响应安全问题。
• 升级：整合上游升级，例如新版本的 V8、Chromium 和 Node。
• 网站：维护和改进Electron 网站。

这些组将相互协调，但每个组都有自己的会议时间表和议程，以便独立高效地工作。有关这些组的更多详细信息，请查阅治理存储库。

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

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

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

• 治理存储库和章程包含了新治理结构的信息。
• 每个工作组都有自己的页面：社区、文档与工具、外展、发布、安全、升级和网站。
• 您可以通过提交议题或发送邮件至 info@electronjs.org 来联系维护者。

从 Electron v4.0 开始，Electron 团队将停止支持 32 位 Linux (ia32 / i386)。支持 32 位 Linux 安装的最后一个 Electron 版本是 Electron v3.1，它将接收支持版本（support releases），直到 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 作为局部句柄（local handles）。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，它作为 Node.js 本身的一部分，与 V8 分开维护，旨在使原生插件不受底层 JavaScript 引擎变化的影响。您可以在 Node.js 网站上的 N-API 文档中找到更多信息。

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

如果您在应用中使用了 Node.js 的原生插件，并且由于此问题导致原生插件无法构建，请与插件的作者确认是否已发布修复此问题的新版本。如果没有，联系作者（或发起一个 Pull Request！）可能是您最好的选择。

Electron 现在使用 GN 来构建自身。以下是讨论原因。

GYP 和 GN

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

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

Electron 历来在主 Electron 代码和 libchromiumcontent（Electron 包装 Chromium 'content' 子模块的部分）之间保持分离。Electron 继续使用 GYP，而 libchromiumcontent 作为 Chromium 的一部分，则在 Chromium 切换到 GN 时也进行了切换。

就像齿轮无法完全啮合一样，使用这两种构建系统之间存在摩擦。维护兼容性容易出错，例如需要细致地在 Chromium、Node、V8 和 Electron 之间保持编译器标志和 #defines 的同步。

为了解决这个问题，Electron 团队一直在努力将所有内容迁移到 GN。今天，将剩余的 GYP 代码从 Electron 中移除的提交已合入 master 分支。

这对您意味着什么

如果您正在贡献 Electron 本身，从 master 或 4.0.0 分支检出和构建 Electron 的过程与 3.0.0 及更早版本有很大不同。请参阅GN 构建说明了解详情。

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

这对 Electron 意味着什么

GN 比 GYP 更快，而且其文件更易读、更易维护。此外，我们希望使用单一的构建配置系统能减少将 Electron 升级到新版本 Chromium 所需的工作量。

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

• 这也让 Electron 更容易在 Electron、Chromium 和 Node 的统一构建中使用 BoringSSL——这在以前是存在问题的。

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

在 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/。

更多信息​

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

• 什么是证书透明度？
• Symantec 知识库文章
• Chrome 问题 664177
• Chrome 修复问题 664177
• libchromiumcontent 问题 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 版本开始，我们已开始同时在 npm 上发布 electron 和 electron-prebuilt 包。这两个包是相同的。我们选择在一段时间内继续使用这两个名称发布包，以免给当前在项目中使用 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 仓库。