The Electron team is excited to announce the release of Electron 6.0.0! You can install it with npm via
npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!
Today marks a first for the Electron project: this is the first time we've made a stable Electron release on the same day as the corresponding Chrome stable release! 🎉
This release also includes improvements to Electron's APIs. The release notes have a more complete list, but here are the highlights:
Electron 6.0 continues the modernization initiative started in 5.0 to improve Promise support.
These functions now return Promises and still support older callback-based invocation:
These functions now have two forms, synchronous and Promise-based asynchronous:
These functions now return Promises:
Electron Helper (Renderer).app,
Electron Helper (GPU).app and
Electron Helper (Plugin).app
In order to enable the hardened runtime, which restricts things like writable-executable memory and loading code signed by a different Team ID, special code signing entitlements needed to be granted to the Helper.
To keep these entitlements scoped to the process types that require them, Chromium added three new variants of the Helper app: one for renderers (
Electron Helper (Renderer).app), one for the GPU process (
Electron Helper (GPU).app) and one for plugins (
Electron Helper (Plugin).app).
electron-osx-sign to codesign their Electron app shouldn't have to make any changes to their build logic. If you're codesigning your app with custom scripts, you should ensure that the three new Helper applications are correctly codesigned.
In order to package your application correctly with these new helpers you need to be using
firstname.lastname@example.org or higher. If you are using
electron-builder you should follow this issue to track support for these new helpers.
This release begins laying the groundwork for a future requirement that native Node modules loaded in the renderer process be either N-API or Context Aware. The reasons for this change are faster performance, stronger security, and reduced maintenance workload. Read the full details including the proposed timeline in this issue. This change is expected to be completed in Electron v11.
net.IncomingMessageheaders have changed slightly to more closely match Node.js behavior, particularly with the value of
set-cookieand how duplicate headers are handled. #17517.
shell.showItemInFolder()now returns void and is an asynchronous call. #17121
Apps must now explicitly set a log path by calling the new function
End of Support for 3.x.y
Per our support policy, 3.x.y has reached end of life. Developers and applications are encouraged to upgrade to a newer version of Electron.
Programa de Feedback de Aplicativos
We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.
In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 7.0.0 schedule maps out key dates in the Electron 7 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.
For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.