Electron 22.0.0 已发布！ 它包括了一个新的实用进程 API、对 Windows 7/8/8.1 支持的更新，以及对 Chromium 108、V8 10.8 和 Node.js 16.17.1 的升级。 请阅读下文了解更多详情！

Electron 团队很高兴发布了 Electron 22.0.0！ You can install it with npm via npm install electron@latest or download it from our releases website. 继续阅读此版本的详细信息。

如果您有任何反馈，请在Twitter上与我们分享，或加入我们的社区 Discord！ Bug 和功能请求可以在 Electron 的 问题跟踪器 中报告。

Windows 7/8/8.1 支持更新​

Electron 22 将是最后一个支持 Windows 7/8/8.1 的 Electron 主要版本。 Electron 遵循计划中的 Chromium 弃用政策，该政策将 [在 Chromium 109 中弃用 Windows 7/8/8.1 支持（在此处阅读更多信息）](https://support.google.com/chrome/thread/185534985/sunsetting-support-for-windows-7-8-8-1-in-early -2023?hl=en)。

Electron 23 及以后的主要版本将不支持 Windows 7/8/8.1。

重要变化​

UtilityProcess API #36089​

新的 UtilityProcess 主进程模块允许创建仅集成 Node.js 的轻量级 Chromium 子进程，同时还允许使用 MessageChannel 与沙盒渲染器进行通信。 该API是基于Node.js的 child_process.fork 设计的，以允许更容易的过渡，一个主要的区别是，入口点 modulePath 必须来自打包的应用程序内，以允许只加载受信任的脚本。 此外，该模块默认情况下会阻止与渲染器建立通信通道，以保证主进程是应用程序中唯一受信任进程。

您可以在此处阅读有关我们文档中的新 UtilityProcess API 的更多信息。

其他显著的更改​

• 添加了对 Linux 和 Windows 上的 Web Bluetooth pin 配对的支持。 #35416
• 添加了 LoadBrowserProcessSpecificV8Snapshot 作为新的 Fuse（引信)，让主/浏览器进程从位于 browser_v8_context_snapshot.bin的文件加载其 v8 快照。 任何其他进程将使用与之相同的路径。 #35266
• 添加了 WebContents.opener 以访问窗口打开器和 webContents.fromFrame(frame) 以获取与 WebFrameMain 实例对应的 WebContents。 #35140
• 通过新的会话处理程序 ses.setDisplayMediaRequestHandler 添加了对 navigator.mediaDevices.getDisplayMedia 的支持。 #30702

Electron 将在 Electron23 中开始结束 Windows 7, Windows 8 和 Windows 8.1 的支持。

In line with Chromium’s deprecation policy, Electron will end support of Windows 7, Windows 8 and Windows 8.1 beginning in Electron 23. This matches Microsoft's end of support for Windows 7 ESU and Windows 8.1 extended on January 10th, 2023.

Electron 22 will be the last Electron major version to support Windows versions older than 10. Electron 23 及以后的主要版本将不支持 Windows 7/8/8.1。 Older versions of Electron will continue to function on Windows 7, and we will continue to release patches for Electron the 22.x series until May 30 2023, when Electron will end support for 22.x (according to our support timeline).

为什么要废弃它？​

Electron 遵循计划中的Chromium 弃置策略，它将不支持Chromium 109 (在这里阅读更多关于 Chromium 的时间表)。 Electron 23 将包含 Chromium 110, 它不支持旧版本的Windows。

因此含有Chromium 108的Electron 22将是最后一个支持版本。

弃用时间表​

The following is our planned deprecation timeline:

• 2022 年 12 月：Electron 团队将度过一段假期，此时将不会有大的动向。
• January 2023: Windows 7 & 8 related issues are accepted for all supported release branches.
• 2023 年 2 月 7 日: Electron 23 将发布。
• February 8 2023 - May 29 2023: Electron will continue to accept fixes for supported lines older than Electron 23.
• 2023: Electron 22 迎来其支持周期的终结。

这对开发者意味着什么：

• The Electron team will accept issues and fixes related to Windows 7/8/8.1 for stable supported lines, until each line reaches the end of its support cycle.
  • This specifically applies to Electron 22, Electron 21 and Electron 20.
• New issues related to Windows 7/8/8.1 will be accepted for Electron versions older than Electron 23.
  • New issues will not be accepted for any newer release lines.
• Once Electron 22 has reached the end of its support cycle, all existing issues related to Windows 7/8/8.1 will be closed.

下一步​

Please feel free to write to us at info@electronjs.org if you have any questions or concerns. 您也可以在我们官方的 Electron Discord 中找到社区支持。

2022年12月Electron项目将进入暂停状态，然后在2023年1月全速恢复。

通过 GIPHY

12月保持不变的内容​

1. 必要时将发布零日和其他与安全相关的主版本。 安全事件应该通过 SECURITY.md 报告。
2. 行为准则报告和审核将继续。

12月变动的内容​

1. 12 月没有新的稳定版。 12 月的最后两周没有 Nightly 和 Alpha 版本。
2. 除了少数例外，不会合并请求的审核或合并。
3. 任何仓库上都不会有问题跟进更新。
4. 维护人员不会提供 Discord 调试帮助。
5. 社交媒体暂停更新内容。

为什么会发生这种情况？​

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 Forge 是一个用于打包和分发 Electron 应用程序的工具。 它将 Electron 的构建工具生态系统统一到一个可扩展的界面中，这样每个人都可以直接上手制作 Electron 应用。

它的亮点：

• 📦 应用打包和代码签名
• 🚚 Windows、macOS 和 Linux 上的可定制安装程序（DMG、deb、MSI、PKG、AppX 等）
• ☁️ 云提供商（GitHub、S3、Bitbucket 等）的自动化发布流程
• ⚡️ 易于使用的 Webpack 和 TypeScript 样板模板
• ⚙️ 原生 Node.js 模块支持
• 🔌 可扩展的 JavaScript 插件 API

v6 中有什么新功能？​

完全重构​

从 v1 到 v5，Electron Forge 是在现已停止的 electron-compile 项目的基础上进行开发的。 Forge 6 是对项目的完全重构，具有新的模块化架构，可以扩展以满足大多数 Electron 应用程序的需求。

在过去的几年里，Forge v6.0.0-beta 已经实现了与 v5 相同的功能，并且代码流失速度显着放缓，使该工具为普遍采用做好了准备。

官方支持​

从历史上看，Electron 的维护者对构建工具不感兴趣，而是把这个任务留给各个由社区维护的工具包。 然而，随着 Electron 项目的成熟，新的 Electron 开发人员越来越难以理解他们需要哪些工具来构建和分发他们的应用程序。

为了在分发过程中帮助指导 Electron 开发人员，我们决定让 Forge 成为 Electron 的官方内置的构建体系。

在过去的一年里，我们一直在慢慢地将 Forge 集成到官方的 Electron 文档中，最近我们将 Forge 从其在 electron-userland/electron-forge 的旧地址转移到了 electron/forge 存储库。 现在，我们终于准备好向广大用户发布 Electron Forge 了！

入门指南​

初始化一个新的 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 文档中的入门指南。

导入现有项目​

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 服务器！

为什么要切换到 Forge？​

如果您已经有了用于打包和发布 Electron 应用程序的工具，那么采用 Electron Forge 带来的好处仍然可以超过最初地转换成本。

我们认为使用 Forge 有两个主要好处：

1. Forge 在 Electron 支持的新功能出现后，会立即得到这些新功能并用于应用程序的构建。 在这种情况下，您不需要自己编写新的工具去实现，或者在升级之前等待其他更新包实现。 有关最近的示例，请参阅 macOS 通用二进制文件和 ASAR 完整性检查。

2. 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年及以后的项目方向。 在这四天的会议中，核心维护者和受邀合作者讨论了新的倡议、维护痛点和总体项目健康状态。

今后，团队仍将全力以赴，定期快速发布Chromium 升级和 bug 修复，以确保 Electron 对每个人都更安全、更高效。 我们也有一些令人兴奋的项目正在进行，我们很乐意与社区分享！

变革性的新 API​

Electron 项目中需要达成共识的主要 API 提案需要通过申请 (RFC) 流程后，由我们的 API 工作组成员审核。

今年，我们推动了两项主要提案，这些提案有可能为 Electron 应用程序开启一个新的功能维度。 这些建议是实验性很强的，在这里可以先睹为快！

新的原生附加组件 (C API)​

该提案概述了一个新的 Electron C API 层，它将允许应用程序开发人员编写他们自己的原生 Node 插件用于访问 Electron 内部资源，类似于 Node 的 Node-API。 有关拟议新 API 的更多信息可以在这里找到。

示例：使用 Chromium 资源增强应用程序​

许多 Electron 应用程序都有维护自己的分支，以便直接访问 Chromium 内部资源，而普通的（未修改的）Electron 是无法访问这些资源的。 通过在 C API 层中公开这些资源，这些代码可以作为原生模块与 Electron 一起存在，从而可能减少应用程序开发人员的维护负担。

开放 Chromium 的 UI 层 (Views API)​

在底层，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 Forge v6 稳定发布​

自从该框架诞生以来，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！ You can install it with npm via npm install electron@latest or download it from our releases website. 继续阅读此版本的详细信息。

如果您有任何反馈，请在Twitter上与我们分享，或加入我们的社区 Discord！ Bug 和功能请求可以在 Electron 的 问题跟踪器 中报告。

Electron 20.0.0 已发布！ 它包括升级到 Chromium 104, V8 10.4, 和 Node.js 16.15.0。 请阅读下文了解更多详情！

Electron 团队很高兴发布了 Electron 20.0.0！ You can install it with npm via npm install electron@latest or download it from our releases website. 继续阅读有关此版本的详细信息，并请分享您的任何反馈！

Electron 21及更高版本将启用 V8 内存隔离区，这将对一些原生模块产生影响。

在Electron 21中，我们将启用 V8沙盒指针， Electron中，Chrome 决定在Chrome 103中执行相同的操作。 这对原生模块有一定的影响。 此外，我们曾在 Electron 14 中启用了 指针压缩 相关技术。 我们当时没有对此进行过多地讨论，但指针压缩对V8最大堆大小有影响。

这两种技术一旦启用，将对安全、性能和内存使用大有裨益。 但是，启用它们也有一些缺点。

启用沙盒指针的主要缺点是，不再允许进行指向外部 ("off-heap") 内存 的数组缓冲区的操作。 这意味着在V8中依赖于此功能的原生模块将需要重构才能在Electron 20及更高版本中继续工作。

启用指针压缩的主要缺点是， V8堆的最大大小限制为4GB。 这方面的确切细节有点复杂 - 例如，ArrayBuffers与V8堆的其余部分分开计数，但存在一些 自己的限制。

Electron 升级团队 认为，启用指针压缩和V8内存隔离区的好处超过了缺点。 这样做主要有三个原因：

1. 它使Electron更接近近Chromium。 Electron在复杂的内部细节（如V8配置）中与Chromium的分歧越小，我们就越不可能意外引入错误或安全漏洞。 Chromium的安全团队非常优秀，我们要确保我们能够更多的用到他们的工作成果。 此外，如果一个错误只影响Chromium中未使用的配置，那么修复它不太可能是Chromium团队的首要任务。
2. 它表现得更好。 指针压缩可将 V8 堆大小减小至40%，使CPU 和GC性能提高5%-10%。 对于绝大多数不会碰到4GB堆大小限制并且不使用需要外部缓冲区的本机模块的Electron应用程序，这些都是显着的性能优势。
3. 它更安全。 一些Electron应用程序运行不受信任的JavaScript（希望遵循我们的 安全建议！），对于这些应用程序，启用V8内存笼可以保护它们免受大量令人讨厌的V8漏洞的影响。

最后，对于确实需要更多堆大小的应用，有一些解决方法。 例如，可以在应用（在禁用指针压缩的情况下生成）中包含 Node.js 的副本，并将占用大量内存的工作移动到子进程。 虽然有些复杂，但如果您决定要为特定用例进行不同的权衡，也可以构建禁用指针压缩的Electron的自定义版本。 最后，在不久的将来， wasm64 将允许在Web和Electron中使用WebAssembly构建的应用程序使用超过4GB的内存。

常见问题 (FAQ)​

如何知道我的应用是否受到此更改的影响？​

尝试使用ArrayBuffer包装外部存储器将在Electron 20 +的运行时崩溃。

如果你没有在应用中使用任何原生 Node 模块，那么你是安全的 - 目前没有办法从纯 JS 触发此崩溃。 此更改仅影响原生 Node 模块，这些模块在 V8 堆之外分配内存（例如，使用 malloc 或 new），然后使用 ArrayBuffer 包装外部内存。 这是一个相当罕见的用例，但有些模块确实使用这种技术，并且这些模块需要重构才能与Electron 20 +兼容。

如何测量我的应用正在使用多少 V8 堆内存，以了解我的应用是否接近 4GB 限制？​

在渲染器进程中，您可以使用 performance.memory.usedJSHeapSize，这将返回 V8 堆使用情况（以字节为单位）。 在主过程中，您可以使用 process.memoryUsage().heapUsed，这是可比较的。

什么是 V8 内存隔离区？​

一些文档将其称为“V8沙盒”，但该术语很容易与Chromium中发生的 其他类型的沙盒 混淆，因此我将坚持使用术语“内存隔离区”。

有一种相当常见的V8漏洞利用，如下所示：

1. 在 V8 的 JIT 引擎中查找错误。 JIT 引擎分析代码，以便能够省略慢速运行时类型检查并生成快速的机器代码。 有时，逻辑错误意味着它搞错了这个分析，并省略了它实际需要的类型检查——比如说，它认为x是一个字符串，但实际上它是一个对象。
2. 滥用这种混淆来覆盖 V8 堆中的一些内存，例如，指向 ArrayBuffer 开头的指针。
3. 现在你有一个 ArrayBuffer，它指向你喜欢的任何位置，所以你可以在过程中读取和写入 任何 内存，甚至是 V8 通常无法访问的内存。

V8 内存隔离区是一种旨在明确防止此类攻击的技术。 实现此目的的方法是 _不在 V8 堆_存储任何指针。 相反，对 V8 堆内其他内存的所有引用都存储为从某个保留区域的开头开始的偏移量。 然后，即使攻击者设法破坏了ArrayBuffer的基址，例如通过利用V8中的类型混淆错误，他们能做的最糟糕的事情就是在笼子里读取和写入内存，他们可能已经这样做了。 关于V8内存隔离区的工作原理还有很多可供阅读的内容，所以我不会在这里进一步详细介绍 - 开始阅读的最佳位置可能是Chromium团队 高级设计文档。

我想重构一个Node原生模块来支持Electron 21+。 我该怎么做？​

有两种方法可以重构原生模块以使其与 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！ You can install it with npm via npm install electron@latest or download it from our releases website. 继续阅读有关此版本的详细信息，并请分享您的任何反馈！

Electron 发布时间变更​

该项目正在恢复其支持最新三个主要版本的早期政策。 查看我们的版本文档 以了解更多关于 Electron 版本控制和支持的详细信息。 暂时有四个主要版本，以帮助用户适应从 Electron 15 开始的新版本发布节奏。 您可以在此处阅读 完整详细信息。

Electron is changing its primary S3 bucket, you may need to update your build scripts

What is happening?

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.

How might this impact you?

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.

What about existing data?

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.