The Electron project will pause for the month of December 2024, then return to full speed in January 2025.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. 2024's last stable branch releases for the year, which include Electron 31, 32, and 33, will occur the week of December 1st. There will be no additional planned releases in December.
2. No Nightly and Alpha releases for the last two weeks of December.
3. With few exceptions, no pull request reviews or merges.
4. No issue tracker updates on any repositories.
5. No Discord debugging help from maintainers.
6. No social media content updates.

See you all in 2025!

The Electron project will pause for the month of December 2023, then return to full speed in January 2024.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. Electron 28.0.0 will be released on December 5th. After Electron 28, there will be no new Stable releases in December.
2. No Nightly and Alpha releases for the last two weeks of December.
3. With few exceptions, no pull request reviews or merges.
4. No issue tracker updates on any repositories.
5. No Discord debugging help from maintainers.
6. No social media content updates.

Going forward​

This is our third year running our quiet period experiment, and we've had a lot of success so far in balancing a month of rest with maintaining our normal release cadence afterwards. Therefore, we've decided to make this a regular part of our release calendar going forward. We'll still be putting a reminder into the last stable release of every calendar year.

See you all in 2024!

Первый коммит в репозитарии electron/electron был совершён 13 марта 2013 года¹.

После 10 лет и 27147 коммитов от 1192 различных участников, на сегодняшний день Electron стал одним из самых популярных фреймворков для создания настольных приложений. Эта веха – прекрасная возможность отпраздновать и осмыслить пройденный нами путь, а также поделиться тем, чему мы научились на этом пути.

Нас бы не было здесь сегодня без всех, кто посвятил свое время и усилия участию в проекте. Хотя коммиты исходного кода всегда являются наиболее заметным вкладом, мы также должны признать усилия людей, которые сообщают об ошибках, поддерживают пользовательские модули, предоставляют документацию и переводы, а также участвуют в жизни сообщества Electron в киберпространстве. Каждый вклад бесценен для нас, сопровождающих.

Прежде чем мы продолжим публикацию: спасибо вам. ❤️

Как мы здесь оказались?​

Atom Shell был создан как основа для редактора GitHub Atom, который был запущен в публичной бета-версии в апреле 2014 года. Он был создан с нуля как альтернатива веб-ориентированным фреймворкам для рабочего стола, доступным в то время (node-webkit и Chromium Embedded Framework). У него была потрясающая особенность: встраивание Node.js и Chromium для создания мощной настольной среды выполнения веб-технологий.

Уже через год возможности и популярность Atom Shell начали стремительно расти. Крупные компании, стартапы и отдельные разработчики начали создавать приложения на его основе (среди ранних последователей – Slack, GitKraken и WebTorrent), и проект был переименован в Electron.

С этого момента Electron начал работать и никогда не останавливался. Вот данные о количестве загрузок за неделю, предоставленные сайтом npmtrends.com:

Electron v1 был выпущен в 2016 году с обещаниями повысить стабильность API, улучшить документацию и инструментарий. Electron v2 был выпущен в 2018 году, в нем появилась семантическая версионность, благодаря которой разработчикам Electron стало проще отслеживать цикл выпуска.

В Electron v6 мы перешли на регулярный 12-недельный цикл выпуска основных версий, чтобы соответствовать таковому в Chromium. Это решение изменило менталитет проекта, превратив «наличие самой актуальной версии Chromium» из желаемого в приоритетное направление. Это позволило сократить количество технических долгов между обновлениями, что облегчает нам поддержание Electron в актуальном и безопасном состоянии.

С тех времен, мы были трудоголиками, выпуская новую версию Electron в тот же день, как и Chromium. К моменту, когда Chromium уменьшил время между выпусками до 4 недель в 2021, мы лишь пожали плечами и увеличили наш цикл обновлений до 8 недель соответственно.

Теперь мы на Electron v23 (счет продолжается) и до сих пор преданны созданию лучшей среды создания настольных предложений для различных платформ. Даже учитывая бум создания JavaScript инструментов для разработчиков в последние годы, Electron остался стабильным, протестированным в боях украшением структуры для настольных приложений. Приложения Electron на сегодняшний день являются повсеместными: вы можете программировать с помощью Visual Studio Code, проектировать дизайн с Figma, общаться со Slack и делать заметки с Notion (среди многих других вариантов). Мы невероятно гордимся этим достижением и благодарны каждому, кто сделал это возможным.

Чему мы научились на этом пути?​

Путь к отметке десяти лет был долгий и извилистый. Вот несколько ключевых вещей, которые помогли нам поддерживать стабильность огромного проекта с открытым исходным кодом.

Масштабирование распределенных решений с помощью модели управления​

Одной из сложных задач, которую нам пришлось преодолеть, стала разработка направления проекта, как только Electron впервые получил огромную популярность. Как мы справляемся с организацией команды, составляющей несколько десятков инженеров, распределенных между компаниями, странами и временными зонами?

В первые дни, группа, поддерживающая Electron, опиралась на неформальную координацию, что было быстро и легко для небольших проектов, но не могло расширять сотрудничество. В 2019 году, мы перешли на модель управления, в котором различные рабочие группы имели формальные сферы ответственности. Это было полезно в упрощении процессов и присвоении частей работы к определенным людям, поддерживающим проект. За что отвечают Working Group (WG) на сегодняшний день?

• Выпуском версий Electron (Releases WG)
• Обновлением Chromium и Node.js (Upgrades WG)
• Управлением публичным дизайном API (API WG)
• Поддержка защиты Electron (Security WG)
• Поддержка вебсайта, документации и инструментария (Ecosystem WG)
• Общественная и корпоративная связь (Outreach WG)
• Модерация сообщества (Community & Safety WG)
• Поддержка нашей инфраструктуры, инструментов поддержки и облачных сервисов (Infrastructure WG)

Примерно в то же время, как мы сменили модель управления, мы также поменяли владельца с GitHub'а на OpenJS Foundation. Хоть и первоначальная основная команда по-прежнему работает в Microsoft сегодня, они являются лишь частью более крупной группы сотрудников, которые формируют управление Electron. ²

Хотя эта модель и не является идеальной, она хорошо поработала во время глобальной пандемии и текущих макроэкономических потрясений. Заходя наперед, мы планируем пересмотреть управленческий устав, чтобы он повел нас вперед ко второму десятилетию Electron.

Сообщество​

Вклад сообщества в открытый исходный код огромно, особенно когда наша команда по связи с сообществом составляет десятки инженеров с припиской "менеджер сообщества". Тем не менее, быть огромным проектом с открытым исходным кодом означает наличие огромного числа пользователей, и использование их энергии построения пользовательской экосистемы Electron является важнейшей составляющей поддержки здоровья проекта.

Что мы делаем для развития поддержки связи с сообществом?

Создание виртуальных сообществ​

• В 2020 году мы запустили наш Discord сервер. Ранее у нас был раздел на форуме Atom, однако мы решили использовать более неформальную платформу для ведения дискуссий между людьми, поддерживающими проект и разработчиками Electron, а также для общей информационной помощи в исправлении ошибок.
• В 2021 году мы создали пользовательскую группу Electron China с помощью @BlackHole1. Эта группа играла важную роль в развитии Electron для пользователей из китайской быстрорастущей технологической сцены, предоставляя им место для обмена идеями и обсуждения Electron за пределами англоговорящего сообщества. Мы также хотели бы поблагодарить cnpm за работу и поддержку ночных обновлений Electron в китайском зеркале для npm.

Участие в известных и открытых мероприятиях​

• Мы празднуем Hacktoberfest каждый год, начиная с 2019. Hacktoberfest это ежегодное мероприятие, посвященное проектам с открытым исходным кодом, организованное DigitalOcean, и мы получаем десятки энтузиастов каждый год, жаждущих оставить свой след на ПО с открытым исходным кодом.
• В 2020 году мы участвовали в первой части Google Season of Docs, где мы работали вместе с @bandantonio, чтобы переработать учебный процесс Electron для новых пользователей.
• В 2022 году мы начали обучать студентов Google Summer of Code в первый раз. @aryanshridhar провела невероятную работу, чтобы переработать основную версию Electron Fiddle, а именно: переработать загрузочную логику и перенести ее сборщик на webpack.

Автоматизация производства!​

Сегодня, команда управления Electron составляет около 30 активных разработчиков. Меньше чем половина из нас работают над проектом полный рабочий день, а это значит, что у нас впереди еще много работы. Что мы делаем для поддержки быстрой работоспособности? Наш девиз заключается в том, что компьютеры - вещь дешевая, а человеческое время - вещь дорогая. Ну как типичные инженеры, мы разработали автоматический инструментарий поддержки для облегчения нашей жизни.

Not Goma​

Ядро кода Electron - это код на C++, от чего время сборки всегда играл ограничивающий фактор в том, насколько быстро мы могли исправлять ошибки и добавлять новые возможности. В 2020 году мы запустили Not Goma, особый, направленный на язык Electron, бэкенд для распределенного компилятора Goma от Google. Not Goma обрабатывает заявки от авторизированных пользовательских машин, и распределяет процесс между сотнями ядер в бэкенде. Она также сохраняет результат компиляции для того, чтобы другому человеку, который компилирует те же файлы, надо было только загрузить предварительно скомпилированный результат.

С момента запуска Not Goma, время компиляции для поддержки сократилась с масштаба часов до масштабов минут. Стабильное интернет-соединение стало минимальным требованием для разработчиков, чтобы компилировать Electron!

Фактор Непрерывной Аутентификации​

Continuous Factor Authentication (CFA) является автоматизированным слоем вокруг Двухфакторной Аутентификационной (2FA) системы npm, которую мы комбинируем с семантическим обновлением для управления безопасностью и автоматическим выпуском обновлений различных пакетов npm для @electron/.

Хоть семантический выпуск версий уже автоматизирует процесс публикации npm пакетов, он требует выключения двухфакторной аутентификации или секретный токен, который обходит это ограничение.

Мы создали CFA для предоставления одноразового пароля на основе времени (TOTP) для npm 2FA с целью произвольной работы Cl, что позволяет нам использовать автоматический семантический выпуск, сохраняя при этом дополнительный слой безопасности в виде двухфакторной аутентификации.

Мы используем CFA в интеграции с фронтендом Slack, что позволяет разработчикам проверять публикацию пакетов с любого устройства, в котором есть Slack до тех пор, пока у них есть свой генератор TOTP.

Sheriff​

Sheriff это инструмент с открытым исходным кодом, который мы написали для автоматизации управления правами доступа в GitHub, Slack и Google Workspace.

Ключевая особенность Sheriff - управление правами доступа является прозрачным процессом. Он использует один конфигурационный файл YAML, который определяет права на все платформы, перечисленные выше. С Sheriff, получение статуса соавтора в репозитории или создание нового списка рассылок становится таким же легким, как и получение одобрения и слияния PR.

У Sheriff также есть журнал аудита, который отправляет сообщение в Slack, предупреждая администраторов о подозрительной активности внутри организации Electron.

...и всех наших ботов на GitHub​

GitHub это платформа с богатым количеством расширений API и их собственной автоматической структурой для создания приложений под названием Probot. Чтобы помочь нам сфокусироваться на более творческих частях нашей работы, мы создали набор маленьких ботов, которые выполняют за нас нашу грязную работу. Вот несколько примеров:

• Sudowoodo автоматизирует процесс выпуска Electron с начала и до конца, от отказа от определенных сборок и до загрузки финальных ресурсов в GitHub и npm.
• Trop автоматизирует бэкпортинг Electron, пытаясь выбрать только лучшие изменения веток предыдущих обновлений, основанные на метках GitHub PR.
• Roller автоматизирует ротационные обновления дополнений для Chromium и Node.js, которые требуются в Electron.
• Cation это бот для проверки статуса electron/electron PR.

В целом, наша маленькая семейка ботов дала нам огромное ускорение производительности разработчиков!

What’s next?​

Вступая в наше второе десятилетие, вы можете спросить: "А что дальше будет с Electron?"

Мы будем синхронизироваться с выпуском изменений Chromium, выпуская большие обновления для Electron каждые 8 недель, держа его обновленной и выбирая только лучшее из веб-платформ и Node.js, пока поддерживаем стабильность и безопасность приложений для предприятий.

Мы сообщаем о предстоящих инициативах, как только они обретут конкретные очертания. Если вы хотите быть в курсе будущих обновлений и общих обновлений проекта, вы можете читать нас в нашем блоке, а также подписаться на нас в социальных сетях (Twitter и Mastodon)!

Electron will end support of Windows 7, Windows 8 and Windows 8.1 beginning in Electron 23.

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. Windows 7/8/8.1 will not be supported in Electron 23 and later major releases. 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).

Why deprecate?​

Electron follows the planned Chromium deprecation policy, which will deprecate support in Chromium 109 (read more about Chromium's timeline here). Electron 23 will contain Chromium 110, which won’t support older versions of Windows.

Electron 22, which contains Chromium 108, will thus be the last supported version.

Deprecation timeline​

The following is our planned deprecation timeline:

• December 2022: The Electron team is entering a quiet period for the holidays
• January 2023: Windows 7 & 8 related issues are accepted for all supported release branches.
• February 7 2023: Electron 23 is released.
• February 8 2023 - May 29 2023: Electron will continue to accept fixes for supported lines older than Electron 23.
• May 30 2023: Electron 22 reaches the end of its support cycle.

What this means for developers:

• 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.

What's next​

Please feel free to write to us at info@electronjs.org if you have any questions or concerns. You can also find community support in our official Electron Discord.

The Electron project will pause for the month of December 2022, then return to full speed in January 2023.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. No new Stable releases in December. No Nightly and Alpha releases for the last two weeks of December.
2. With few exceptions, no pull request reviews or merges.
3. No issue tracker updates on any repositories.
4. No Discord debugging help from maintainers.
5. No social media content updates.

Why is this happening?​

With the success of December Quiet Month 2021, we wanted to bring it back for 2022. December continues to be a quiet month for most companies, so we want to give our maintainers a chance to recharge. Everyone is looking forward to 2023, and we expect good things to come! We encourage other projects to consider similar measures.

Last month, Electron’s maintainer group met up in Vancouver, Canada to discuss the direction of the project for 2023 and beyond. Over four days in a conference room, core maintainers and invited collaborators discussed new initiatives, maintenance pain points, and general project health.

Going forward, the team will still be fully dedicated to releasing regular and rapid Chromium upgrades, fixing bugs, and making Electron more secure and performant for everyone. We also have a few exciting projects in the works we would love to share with the community!

Transformative new APIs​

Major API proposals in the Electron project that require consensus go through a Request for Comments (RFC) process, which gets reviewed by members of our API Working Group.

This year, we have driven forward two major proposals that have the potential to unlock a new dimension of capabilities for Electron apps. These proposals are highly experimental, but here’s a sneak peek of what to expect!

New native addon enhancements (C APIs)​

This proposal outlines a new layer of Electron C APIs that will allow app developers to write their own Native Node Addons that interface with Electron’s internal resources, similar to Node’s own Node-API. More information about the proposed new API can be found here.

Example: Supercharging apps with Chromium resources​

Many Electron apps maintain their own forks to interact directly with Chromium internals that would otherwise be inaccessible with vanilla (unmodified) Electron. By exposing these resources in the C API layer, this code can instead live as a native module alongside Electron, potentially reducing app developer maintenance burden.

Exposing Chromium’s UI layer (Views API)​

Under the hood, the non-website parts of Chrome’s user interface (UI), such as toolbars, tabs, or buttons, are built with a framework called Views. The Views API proposal introduces parts of this framework as JavaScript classes in Electron, with the eventual goal of allowing developers to create non-web UI elements to their Electron applications. This will prevent apps from having to hack together web contents.

The groundwork to make this new set of APIs possible is currently in progress. Here are a few of the first things you can expect in the near future.

Example: Refactoring the window model with WebContentsView​

Our first planned change is to expose Chrome’s WebContentsView to Electron’s API surface, which will be the successor to our existing BrowserView API (which, despite the name, is Electron-specific code unrelated to Chromium Views). With WebContentsView exposed, we will have a reusable View object that can display web contents, opening the door to making the BrowserWindow class pure JavaScript and eliminating even more code complexity.

Although this change doesn’t provide a lot of new functionality to app developers, it is a large refactor that eliminates a lot of code under the hood, simplifying Chromium upgrades and reducing the risk of new bugs appearing between major versions.

If you’re an Electron developer using BrowserViews in your app: don’t worry, we haven’t forgotten about you! We plan on making the existing BrowserView class a shim for WebContentsView to provide a buffer as you transition to the newer APIs.

See: electron/electron#35658

Example: Scrollable web contents with ScrollView​

Our friends at Stack have been driving an initiative to expose the Chromium ScrollView component to Electron’s API. With this new API, any child View component can be made scrollable horizontally or vertically.

Although this new API fulfills a single smaller functionality, the team’s eventual goal is to build a set of utility View components that can be used as a toolkit to build more complex non-HTML interfaces.

Getting involved​

Are you an Electron app developer interested in either of these API proposals? Although we’re not quite ready to receive additional RFCs, please stay tuned for more details in the future!

Electron Forge v6 stable release​

Since the framework’s inception, Electron’s build tooling ecosystem has been largely community-driven and has consisted of many small single-purpose packages (e.g. electron-winstaller, electron-packager, electron-notarize, electron-osx-sign). Although these tools work well, it’s intimidating for users to piece together a working build pipeline.

To help build a friendlier experience for Electron developers, we built Electron Forge, an all-in-one solution that combines all this existing tooling into a single interface. Although Forge has been in development since 2017, the project has lain dormant for the last few years. However, given community feedback on the state of build tooling in Electron, we have been hard at work on releasing the next-gen stable major version of Forge.

Electron Forge 6 comes with first-class TypeScript and Webpack support, as well as an extensible API that allows developers to create their own plugins and installers.

Stay tuned: announcement coming soon​

If you’re interested in building a project with Forge or building templates or plugins with Forge’s extensible third-party APIs, stay tuned for our official announcement on the Forge v6 stable release sometime this month!

What’s next?​

Aside from the above, the team is always thinking of a bunch of exploratory projects to make the Electron experience better for app developers and end users. Updater tooling, API review processes, and enhanced documentation are other things we are experimenting with. We hope to have more news to share in the near future!

Electron 21 and later will have the V8 Memory Cage enabled, with implications for some native modules.

In Electron 21, we will be enabling V8 sandboxed pointers in Electron, following Chrome's decision to do the same in Chrome 103. This has some implications for native modules. Also, we previously enabled a related technology, pointer compression, in Electron 14. We didn't talk about it much then, but pointer compression has implications for the maximum V8 heap size.

These two technologies, when enabled, are significantly beneficial for security, performance and memory usage. However, there are some downsides to enabling them, too.

The main downside of enabling sandboxed pointers is that ArrayBuffers which point to external ("off-heap") memory are no longer allowed. This means that native modules which rely on this functionality in V8 will need to be refactored to continue working in Electron 20 and later.

The main downside of enabling pointer compression is that the V8 heap is limited to a maximum size of 4GB. The exact details of this are a little complicated—for example, ArrayBuffers are counted separately from the rest of the V8 heap, but have their own limits.

The Electron Upgrades Working Group believes that the benefits of pointer compression and the V8 memory cage outweigh the downsides. There are three main reasons for doing so:

1. It keeps Electron closer to Chromium. The less Electron diverges from Chromium in complex internal details such as V8 configuration, the less likely we are to accidentally introduce bugs or security vulnerabilities. Chromium's security team is formidable, and we want to make sure we are taking advantage of their work. Further, if a bug only affects configurations that aren't used in Chromium, fixing it is not likely to be a priority for the Chromium team.
2. It performs better. Pointer compression reduces V8 heap size by up to 40% and improves CPU and GC performance by 5%–10%. For the vast majority of Electron applications which won't bump into the 4GB heap size limit and don't use native modules that require external buffers, these are significant performance wins.
3. It's more secure. Some Electron apps run untrusted JavaScript (hopefully following our security recommendations!), and for those apps, having the V8 memory cage enabled protects them from a large class of nasty V8 vulnerabilities.

Lastly, there are workarounds for apps that really need a larger heap size. For example, it is possible to include a copy of Node.js with your app, which is built with pointer compression disabled, and move the memory-intensive work to a child process. Though somewhat complicated, it is also possible to build a custom version of Electron with pointer compression disabled, if you decide you want a different trade-off for your particular use case. And lastly, in the not-too-distant future, wasm64 will allow apps built with WebAssembly both on the Web and in Electron to use significantly more than 4GB of memory.

FAQ​

How will I know if my app is impacted by this change?​

Attempting to wrap external memory with an ArrayBuffer will crash at runtime in Electron 20+.

If you don't use any native Node modules in your app, you're safe—there's no way to trigger this crash from pure JS. This change only affects native Node modules which allocate memory outside of the V8 heap (e.g. using malloc or new) and then wrap the external memory with an ArrayBuffer. This is a fairly rare use case, but some modules do use this technique, and such modules will need to be refactored in order to be compatible with Electron 20+.

How can I measure how much V8 heap memory my app is using to know if I'm close to the 4GB limit?​

In the renderer process, you can use performance.memory.usedJSHeapSize, which will return the V8 heap usage in bytes. In the main process, you can use process.memoryUsage().heapUsed, which is comparable.

What is the V8 memory cage?​

Some documents refer to it as the "V8 sandbox", but that term is easily confusable with other kinds of sandboxing that happen in Chromium, so I'll stick to the term "memory cage".

There's a fairly common kind of V8 exploit that goes something like this:

1. Find a bug in V8's JIT engine. JIT engines analyze code in order to be able to omit slow runtime type checks and produce fast machine code. Sometimes logic errors mean it gets this analysis wrong, and omits a type check that it actually needed—say, it thinks x is a string, but in fact it's an object.
2. Abuse this confusion to overwrite some bit of memory inside the V8 heap, for instance, the pointer to the beginning of an ArrayBuffer.
3. Now you have an ArrayBuffer that points wherever you like, so you can read and write any memory in the process, even memory that V8 normally doesn't have access to.

The V8 memory cage is a technique designed to categorically prevent this kind of attack. The way this is accomplished is by not storing any pointers in the V8 heap. Instead, all references to other memory inside the V8 heap are stored as offsets from the beginning of some reserved region. Then, even if an attacker manages to corrupt the base address of an ArrayBuffer, for instance by exploiting a type confusion error in V8, the worst they can do is read and write memory inside the cage, which they could likely already do anyway. There's a lot more available to read on how the V8 memory cage works, so I won't go into further detail here—the best place to start reading is probably the high-level design doc from the Chromium team.

Мне нужен рефакторинг нативного модуля Node для поддержки Electron 21+. Как это сделать?​

There are two ways to go about refactoring a native module to be compatible with the V8 memory cage. The first is to copy externally-created buffers into the V8 memory cage before passing them to JavaScript. This is generally a simple refactor, but it can be slow when the buffers are large. The other approach is to use V8's memory allocator to allocate memory which you intend to eventually pass to JavaScript. This is a bit more involved, but will allow you to avoid the copy, meaning better performance for large buffers.

To make this more concrete, here's an example N-API module that uses external array buffers:

// Create some externally-allocated buffer.
// |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);

This will crash when the memory cage is enabled, because data is allocated outside the cage. Refactoring to instead copy the data into the cage, we get:

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!

This will copy the data into a newly-allocated memory region that is inside the V8 memory cage. Optionally, N-API can also provide a pointer to the newly-copied data, in case you need to modify or reference it after the fact.

Refactoring to use V8's memory allocator is a little more complicated, because it requires modifying the create_external_resource function to use memory allocated by V8, instead of using malloc. This may be more or less feasible, depending on whether or not you control the definition of create_external_resource. The idea is to first create the buffer using V8, e.g. with napi_create_buffer, and then initialize the resource into the memory that has been allocated by V8. It is important to retain a napi_ref to the Buffer object for the lifetime of the resource, otherwise V8 may garbage-collect the Buffer and potentially result in use-after-free errors.

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.

The Electron project will pause for the month of December 2021, then return to full speed in January 2022.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. No new Beta or Stable releases in December. No Nightly releases for the last two weeks of December.
2. With few exceptions, no pull request reviews or merges.
3. No issue tracker updates on any repositories.
4. No Discord debugging help from maintainers.
5. No social media content updates.

Why is this happening?​

In short, while maintainers are happy and engaged with the project, THE WORLD IS TIRED. December is a quiet month for most companies, so we want to give our maintainers a chance to recharge. We encourage other projects to consider similar measures.

Should I be worried about the future of Electron?​

No. We are able to take this step because the project is in good shape. Everyone is looking forward to 2022, and we expect good things to come!

Beginning in September 2021, Electron will release a new major stable version every 8 weeks.

In 2019, Electron moved to a 12 week release cycle to match Chromium's 6 week release cycle. Recently, both Chrome and Microsoft announced changes that made us reconsider Electron's current release cadence:

1. Chromium plans to release a new milestone every 4 weeks, starting with Chrome 94 on September 21st, 2021. This release cadence also adds a new Extended Stable option every 8 weeks, which will contain all updated security fixes.

2. The Microsoft Store will require Chromium-based apps to be no older than within 2 major versions. As an example, if the latest released major version of Chromium is 85, any browser based on Chromium must be on at least Chromium version 83 or higher. This rule includes Electron apps.

Beginning in September 2021, Electron will release a new major stable version every 8 weeks, to match Chromium's 8 week Extended Stable releases.

Our first release with Chromium Extended Stable will be Electron 15 on September 21st, 2021.

Knowing that a release cadence change will impact other downstream applications, we wanted to let our developer community know as soon as possible. Read on for more details about our 2021 release schedule.

Electron 15: Temporary Alpha​

Given that our original Electron 15 release targeted a non-Extended Stable version (Chromium's Extended Stable versions are based on their even-numbered versions), we needed to change our original target release date. However, an Electron app must use the most recent 2 major versions of Chromium to be accepted to the Microsoft Store, which made waiting for two Chromium versions untenable.

With these two requirements, our team faced a timing dilemma. Moving Electron 15 to include Chromium M94 would allow app developers to get on the very first Extended Stable version of Chromium; however, it would also shorten the beta-to-stable cycle to only 3 weeks.

To help with this switchover, Electron will offer a temporary alpha build, only for the Electron 15 release. This alpha build will allow developers more time to test and plan for an Electron 15 release, with a more stable build than our current nightlies.

The alpha channel build will ship for Electron 15 on July 20th, 2021. It will transition to a beta release on September 1st, 2021 with a stable release target of September 21st, 2021. Subsequent Electron releases will not have alpha releases.

2021 Plan for Releases​

Below is our current release schedule for 2021:

Adding the alpha channel extends the development time before Electron 15's launch from 3 weeks to 9 weeks - closer to our new 8 week cycle, while still meeting the requirements for Windows Store submission.

To further help app developers, for the remainder of 2021 until May 2022, we will also be extending our supported versions policy from the latest 3 versions to the latest 4 versions of Electron. That means that even if you can't immediately alter your upgrade schedule, older versions of Electron will still receive security updates and fixes.

Addressing Concerns​

There's a reason we're publishing this post well before this release cycle change is scheduled. We know that a faster release cycle will have a real impact on Electron apps - some of which may already find our major release cadence aggressive.

We've tried to address common concerns below:

❓ Why even make this change? Why not keep the 12 week release cadence?​

To deliver the most up-to-date versions of Chromium in Electron, our schedule needs to track theirs. More information around Chromium's release cycle can be found here.

Additionally, the current 12 week release cadence would be untenable with the Microsoft Store's new submission requirements. Even apps on the latest stable version of Electron would experience a roughly two week period where their app may be rejected under the new security requirements.

Every new Chromium release contains new features, bug fixes / security fixes, and V8 improvements. We want you, as app developers, to have these changes in a timely manner, so our stable release dates will continue to match every other Chromium stable release. As an app developer, you'll have access to new Chromium and V8 features and fixes sooner than before.

❓ The existing 12 week release schedule already moves quickly. What steps are the team taking to make upgrading easier?​

One advantage of more frequent releases is having smaller releases. We understand that upgrading Electron's major versions can be difficult. We hope that smaller releases will introduce fewer major Chromium and Node changes, as well as fewer breaking changes, per release.

❓ Will there been an alpha release available for future Electron versions?​

There are no plans to support a permanent alpha release at this time. This alpha is only intended for Electron 15, as a way to help developers upgrade more easily in the shortened release period.

❓ Will Electron extend the number of supported versions?​

We will be extending our supported version policy from the latest three versions to the latest four versions of Electron until May 2022, with the release of Electron 19. After Electron 19 is released, we'll return to supporting the latest three major versions, as well as the beta and nightly releases.

Questions?​

📨 If you have questions or concerns, please mail us at info@electronjs.org or join our Discord. We know this is a change that will impact many apps and developers, and your feedback is very important to us. We want to hear from you!