跳转到主内容

Electron 版本发布新步伐

· 阅读时间:约 4 分钟
⚡️ 更新日志(2021-07-14):我们走得更快!

在2021 年秋季,Chrome 团队 将发布节奏从每 6 周提高到每 4 周一次。 Electron 也紧随其后发布。 请阅读已更新的 8周模板 博客文章 以了解更多最新信息!

🎉 Electron 每12周将会新发布一个稳定版本! 🎉


⚡️ 哇,那也太快了! 但为什么呢?

简而言之,Chromium 不会停止发布新版本,所以 Electron 的研发也不会减速。

Chromium 的发布遵循每六周更新一次的规划。 为了在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 版和应用稳定性。 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.

📝 Electron 版本简史

在 v3.0.0 之前,有关稳定版本的发布决策没有规律进行。 我们添加了项目的内部时间表与 v3.0.0 和 v4.0.0。 今年早些时候,我们决定首次发布 Electron v5.0.0 的稳定发布日期。 总的来说,宣布我们的稳定发布日期得到了积极的回应,我们很高兴在未来的版本中继续这样做。

为了更好地简化这些与升级相关的工作,我们的更新发布工作组将会和我们的治理组合作 他们使得我们能够更好地确定这项工作的优先级并委派这项工作,我们希望在后续的版本中这些改变都会变得更加明显。

以下是我们和 Chromium 相比的更新计划表:

line graph comparing Electron versus Chromium versions

📨 如果您有任何疑问,请发送电子邮件至 info@electronjs.org

Electron 5.0.0

· 阅读时间:约 5 分钟

Electron 团队很高兴发布了 Electron 5.0.0.0! You can install it with npm via npm install electron@latest or download the tarballs from our releases page. 这次发布包含升级、修复和新功能。 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!


What's New?

Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 5:

Electron 5 also includes improvements to Electron-specific APIs. A summary of the major changes is below; for the full list of changes, check out the Electron v5.0.0 release notes.

Promisification

Electron 5 continues Promisification initiative initiative to convert Electron's callback-based API to use Promises. These APIs were converted for Electron 5:

  • app.getFileIcon
  • contentTracing.getCategories
  • contentTracing.startRecording
  • contentTracing.stopRecording
  • debugger.sendCommand
  • Cookies API
  • shell.openExternal
  • webContents.loadFile
  • webContents.loadURL
  • webContents.zoomLevel
  • webContents.zoomFactor
  • win.capturePage

System colors access for macOS

These functions were changed or added to systemPreferences to access macOS systems' colors:

  • systemPreferences.getAccentColor
  • systemPreferences.getColor
  • systemPreferences.getSystemColor

Process memory information

The function process.getProcessMemoryInfo has been added to get memory usage statistics about the current process.

Additional filtering for remote APIs

To improve security in the remote API, new remote events have been added so that remote.getBuiltin, remote.getCurrentWindow, remote.getCurrentWebContents and <webview>.getWebContents can be filtered.

Multiple BrowserViews on BrowserWindow

BrowserWindow now supports managing multiple BrowserViews within the same BrowserWindow.

重大更改

Defaults for packaged apps

Packaged apps will now behave the same as the default app: a default application menu will be created unless the app has one and the window-all-closed event will be automatically handled unless the app handles the event.

Mixed sandbox

Mixed sandbox mode is now enabled by default. Renderers launched with sandbox: true will now be actually sandboxed, where previously they would only be sandboxed if mixed-sandbox mode was also enabled.

Security improvements

The default values of nodeIntegration and webviewTag are now false to improve security.

Spellchecker now asynchronous

The SpellCheck API has been changed to provide asynchronous results.

Deprecations

The following APIs are newly deprecated in Electron 5.0.0 and planned for removal in 6.0.0:

Mksnapshot binaries for arm and arm64

mksnapshot 用于武器和arm64 的本机二进制二进制已废弃,将在6秒后移除。 .0 可以使用 x64 二进制程序为手臂和arm64 创建快照。

ServiceWorker APIs on WebContents

Deprecated ServiceWorker APIs on WebContents in preparation for their removal.

  • webContents.hasServiceWorker
  • webContents.unregisterServiceWorker

Automatic modules with sandboxed webContents

In order to improve security, the following modules are being deprecated for use directly via require and will instead need to be included via remote.require in a sandboxed webcontents:

  • electron.screen
  • child_process
  • fs
  • os
  • 路径

webFrame Isolated World APIs

webFrame.setIsolatedWorldContentSecurityPolicy,webFrame.setIsolatedWorldHumanReadableName, webFrame.setIsolatedWorldSecurityOrigin have been deprecated in favor of webFrame.setIsolatedWorldInfo.

Mixed sandbox

enableMixedSandbox and the --enable-mixed-sandbox command-line switch still exist for compatibility, but are deprecated and have no effect.

End of support for 2.0.x

Per our supported versions policy, 2.0.x has reached end of life.

应用反馈项目

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.

接下来

在短期内,您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发,包括 Chromium、Node 和 V8。 尽管我们谨慎地避免对发布日期做出承诺,但我们的计划是大约每季度发布一次 Electron 的新主要版本以及这些组件的新版本。 暂定 6.0.0 时间表 展示了 Electron 6 开发生命周期中的关键日期。 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.

Electron 治理

· 阅读时间:约 2 分钟

As Electron grows in popularity for desktop applications, the team working on it has also grown: we have more fulltime maintainers who work for different companies, live in different timezones, and have different interests. We're introducing a governance structure so we can keep growing smoothly.


Why are things changing?

People in the Electron project coordinate in timezones around the world with volunteers, with full-time maintainers, and with several companies who all rely on Electron. Until now, we've been successful with informal coordination; but as the team has grown, we've found that the approach doesn't scale. We also want to make it easier for new contributors to find a place to call home in the project.

工作组

Electron governance includes working groups that are responsible for different parts of the project. We're starting out with seven groups:

  • Community & Safety: Handles Code of Conduct issues.
  • Docs & Tooling: Oversees externally-focused tooling (e.g. Fiddle, Forge) and the Electron documentation.
  • Outreach: Helps grow the Electron community.
  • Releases: Ensures releases are stable and on schedule.
  • Security: Performs security testing and responds to security issues.
  • Upgrades: Integrates upstream upgrades, such as new versions of V8, Chromium, and Node.
  • Website: Maintains and improves the Electron website.

These groups will coordinate with each other, but each has their own meeting schedules and agendas to be productive on their own. More details on these groups are available at the governance repository.

Does this change the Electron project's direction?

This shouldn't have any direct effect on Electron's direction. If our strategy is successful, working groups will make it easier for new contributors to find topics that interest them, and make maintainers' lives simpler by moving discussion unrelated to their day-to-day work to other groups. If that happens, it may indirectly affect things by having more unblocked people working together.

Where can I learn more?

从原生应用到在Electron中使用JavaScript

· 阅读时间:约 4 分钟

C++或Objective-C写的Electron的功能如何被JavaScript访问,以便最终用户可以使用?


背景

Electron 是一个JavaScript 平台,其主要目的是降低门口,让开发人员能够构建强大的桌面应用,而不必担心平台的具体实现情况。 然而,在其核心上,Electron本身仍然需要特定平台的功能以特定的系统语言写入。

In reality, Electron handles the native code for you so that you can focus on a single JavaScript API.

How does that work, though? C++或Objective-C写的Electron的功能如何被JavaScript访问,以便最终用户可以使用?

To trace this pathway, let's start with the app module.

By opening the app.ts file inside our lib/ directory, you'll find the following line of code towards the top:

const binding = process.electronBinding('app');

This line points directly to Electron's mechanism for binding its C++/Objective-C modules to JavaScript for use by developers. This function is created by the header and implementation file for the ElectronBindings class.

process.electronBinding

These files add the process.electronBinding function, which behaves like Node.js’ process.binding. process.binding is a lower-level implementation of Node.js' require() method, except it allows users to require native code instead of other code written in JS. This custom process.electronBinding function confers the ability to load native code from Electron.

When a top-level JavaScript module (like app) requires this native code, how is the state of that native code determined and set? Where are the methods exposed up to JavaScript? What about the properties?

native_mate

目前,这个可以在native_mate找到答案解决方案,Chromium的一个 gin 分支库,它使得在C++和JavaScript的类型交互更加容易

Inside native_mate/native_mate there's a header and implementation file for object_template_builder. This is what allow us to form modules in native code whose shape conforms to what JavaScript developers would expect.

mate::ObjectTemplateBuilder

If we look at every Electron module as an object, it becomes easier to see why we would want to use object_template_builder to construct them. This class is built on top of a class exposed by V8, which is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++. V8 implements the JavaScript (ECMAScript) specification, so its native functionality implementations can be directly correlated to implementations in JavaScript. For example, v8::ObjectTemplate gives us JavaScript objects without a dedicated constructor function and prototype. It uses Object[.prototype], and in JavaScript would be equivalent to Object.create().

To see this in action, look to the implementation file for the app module, atom_api_app.cc. At the bottom is the following:

mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
.SetMethod("getGPUInfo", &App::GetGPUInfo)

In the above line, .SetMethod is called on mate::ObjectTemplateBuilder. .SetMethod can be called on any instance of the ObjectTemplateBuilder class to set methods on the Object prototype in JavaScript, with the following syntax:

.SetMethod("method_name", &function_to_bind)

This is the JavaScript equivalent of:

function App{}
App.prototype.getGPUInfo = function () {
// implementation here
}

This class also contains functions to set properties on a module:

.SetProperty("property_name", &getter_function_to_bind)

.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)

These would in turn be the JavaScript implementations of Object.defineProperty:

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
get() {
return _myProperty
}
})

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
get() {
return _myProperty
}
set(newPropertyValue) {
_myProperty = newPropertyValue
}
})

It’s possible to create JavaScript objects formed with prototypes and properties as developers expect them, and more clearly reason about functions and properties implemented at this lower system level!

The decision around where to implement any given module method is itself a complex and oft-nondeterministic one, which we'll cover in a future post.

Chromium FileReader Vulnerability Fix

· 阅读时间:约 1 分钟

A High severity vulnerability has been discovered in Chrome which affects all software based on Chromium, including Electron.

此漏洞已被分配 CVE-2019-5786。 You can read more about it in the Chrome Blog Post.

Please note that Chrome has reports of this vulnerability being used in the wild so it is strongly recommended you upgrade Electron ASAP.


作用域

This affects any Electron application that may run third-party or untrusted JavaScript.

Mitigation

Affected apps should upgrade to a patched version of Electron.

We've published new versions of Electron which include fixes for this vulnerability:

The latest beta of Electron 5 was tracking Chromium 73 and therefore is already patched:

Further Information

This vulnerability was discovered by Clement Lecigne of Google's Threat Analysis Group and reported to the Chrome team. The Chrome blog post can be found here.

要了解更多关于维护您的 Electron 应用安全的最佳做法,请参阅我们的 安全教程

If you wish to report a vulnerability in Electron, email security@electronjs.org.

不再支持32位Linux

· 阅读时间:约 3 分钟

Electron 团队将停止支持 32 位 Linux (ia32 / i386),从Electron v4.0 开始。 支持基于32位的 Linux 安装的 Electron 最后版本是 Electron v3.1,它将获得支持版本直到Electron v6 被解除。 Support for 64-bit based Linux and armv7l will continue unchanged.


What exactly is Electron no longer supporting?

You may have seen the description "64-bit" and "32-bit" as stickers on your computer or as options for downloading software. The term is used to describe a specific computer architecture. Most computers made in the 1990s and early 2000s were made with CPUs that were based on the 32-bit architecture, while most computers made later were based on the newer and more powerful 64-bit architecture. The Nintendo 64 (get it?) and the PlayStation 2 were the first widely available consumer devices with the new architecture, computers sold after 2010 contained almost exclusively 64-bit processors. As a result, support has been shrinking: Google stopped releasing Chrome for 32-bit Linux in March 2016, Canonical stopped providing 32-bit desktop images in 2017 and dropped support for 32-bit altogether with Ubuntu 18.10. Arch Linux, elementary OS, and other prominent Linux distributions have already dropped support for the aging processor architecture.

Until now, Electron has provided and supported builds that run on the older 32-bit architecture. From release v4.0 onwards, the Electron team will no longer be able to provide binaries or support for 32-bit Linux.

Electron has always been a vibrant open source project and we continue to support and encourage developers interested in building Electron for exotic architectures.

这对开发者意味着什么?

If you are not currently providing 32-bit distributions of your app for Linux, no action is required.

Projects which ship 32-bit Linux Electron applications will need to decide how to proceed. 32-bit Linux will be supported on Electron 3 until the release of Electron 6, which gives some time to make decisions and plans.

这对用户意味着什么?

If you are a Linux user and not sure whether or not you're running a 64-bit based system, you are likely running on a 64-bit based architecture. To make sure, you can run the lscpu or uname -m commands in your terminal. Either one will print your current architecture.

If you are using Linux on a 32-bit processor, you have likely already encountered difficulties finding recently released software for your operating system. The Electron team joins other prominent members in the Linux community by recommending that you upgrade to a 64-bit based architecture.

BrowserView window.open() 漏洞修复

· 阅读时间:约 2 分钟

已发现一个代码漏洞,允许在子窗口中重新启用 Node。


打开一个带有 sandbox: true 或者 nativeWindowOpen: truenodeIntegration: false 这些属性的 BrowserView ,将生成一个 webContents ,里面的window.open 方法可以被调用,同时新打开的子窗口将启用 nodeIntegration。 此漏洞会影响所有受支持的 Electron 版本。

Mitigation

We've published new versions of Electron which include fixes for this vulnerability: 2.0.17, 3.0.15, 3.1.3, 4.0.4, and 5.0.0-beta.2. 我们鼓励所有 Electron 开发者立即更新他们的应用程序到最新稳定版本。

如果由于某些原因,无法升级 Electron 版本,你可以通过禁用所有子网页内容来缓解这个问题:

view.webContents.on('-add-new-contents', (e) => e.preventDefault());

Further Information

此漏洞是由 PalmerAL发现并负责任地报告给Electron项目的。

要了解更多关于维护您的 Electron 应用安全的最佳做法,请参阅我们的 安全教程

If you wish to report a vulnerability in Electron, email security@electronjs.org.

Node.js Native Addons and Electron 5.0

· 阅读时间:约 2 分钟

If you're having trouble using a native Node.js addon with Electron 5.0, there's a chance it needs to be updated to work with the most recent version of V8.


Goodbye v8::Handle, Hello v8::Local

In 2014, the V8 team deprecated v8::Handle in favor of v8::Local for local handles. Electron 5.0 includes a version of V8 that has finally removed v8::Handle for good, and native Node.js addons that still use it will need to be updated before they can be used with Electron 5.0.

The required code change is minimal, but every native Node module that still uses v8::Handle will fail to build with Electron 5.0 and will need to be modified. The good news is that Node.js v12 will also include this V8 change, so any modules that use v8::Handle will need to be updated anyway to work with the upcoming version of Node.

I maintain a native addon, how can I help?

If you maintain a native addon for Node.js, ensure you replace all occurrences of v8::Handle with v8::Local. The former was just an alias of the latter, so no other changes need to be made to address this specific issue.

You may also be interested in looking into N-API, which is maintained separately from V8 as a part of Node.js itself, and aims to insulate native addons from changes in the underlying JavaScript engine. You can find more information in the N-API documentation on the Node.js website.

帮助! I use a native addon in my app and it won't work!

If you're consuming a native addon for Node.js in your app and the native addon will not build because of this issue, check with the author of the addon to see if they've released a new version that fixes the problem. If not, reaching out to the author (or opening a Pull Request!) is probably your best bet.

Electron v5.0.0 Timeline

· 阅读时间:约 2 分钟

Electron公司有史以来第一次很高兴从v5开始公布我们的发布时间表。 .0. 这是我们制定公开和长期时间表的第一步。


As mentioned in our v4.0.0 stable release blog post, we are planning to release approximately quarterly to maintain closer cadence with Chromium releases. Chromium releases a new version very quickly -- every 6 weeks.

Take a look at progression in Electron versus Chromium side-by-side:

line graph comparing Electron versus Chromium versions

In the last half of 2018, our top priority was releasing faster and catching up closer to Chromium. We succeeded by sticking to a predetermined timeline. Electron 3.0.0 and 4.0.0 were released in a 2-3 month timeline for each release. We are optimistic about continuing that pace in releasing 5.0.0 and beyond. With a major Electron release approximately every quarter, we're now keeping pace with Chromium's release cadence. Getting ahead of Chromium stable release is always a goal for us and we are taking steps towards that.

We would love to promise future dates like Node.js and Chromium do, but we are not at that place yet. We are optimistic that we will reach a long-term timeline in the future.

考虑到这一点,我们正在采取第一步,将我们的发布计划发布到v5.0.0。 您可以在这里找到

To help us with testing our beta releases and stabilization, please consider joining our App Feedback Program.

Electron 4.0.0

· 阅读时间:约 7 分钟

The Electron team is excited to announce that the stable release of Electron 4 is now available! You can install it from electronjs.org or from npm via npm install electron@latest. The release is packed with upgrades, fixes, and new features, and we can't wait to see what you build with them. Read more for details about this release, and please share any feedback you have as you explore!


What's New?

A large part of Electron's functionality is provided by Chromium, Node.js, and V8, the core components that make up Electron. As such, a key goal for the Electron team is to keep up with changes to these projects as much as possible, providing developers who build Electron apps access to new web and JavaScript features. To this end, Electron 4 features major version bumps to each of these components; Electron v4.0.0 includes Chromium 69.0.3497.106, Node 10.11.0, and V8 6.9.427.24.

In addition, Electron 4 includes changes to Electron-specific APIs. You can find a summary of the major changes in Electron 4 below; for the full list of changes, check out the Electron v4.0.0 release notes.

Disabling the remote Module

You now have the ability to disable the remote module for security reasons. The module can be disabled for BrowserWindows and for webview tags:

// BrowserWindow
new BrowserWindow({
webPreferences: {
enableRemoteModule: false
}
})

// webview tag
<webview src="http://www.google.com/" enableremotemodule="false"></webview>

See the BrowserWindow and <webview> Tag documentation for more information.

Filtering remote.require() / remote.getGlobal() Requests

This feature is useful if you don't want to completely disable the remote module in your renderer process or webview but would like additional control over which modules can be required via remote.require.

When a module is required via remote.require in a renderer process, a remote-require event is raised on the app module. You can call event.preventDefault() on the the event (the first argument) to prevent the module from being loaded. The WebContents instance where the require occurred is passed as the second argument, and the name of the module is passed as the third argument. The same event is also emitted on the WebContents instance, but in this case the only arguments are the event and the module name. In both cases, you can return a custom value by setting the value of event.returnValue.

// Control `remote.require` from all WebContents:
app.on('remote-require', function (event, webContents, requestedModuleName) {
// ...
});

// Control `remote.require` from a specific WebContents instance:
browserWin.webContents.on(
'remote-require',
function (event, requestedModuleName) {
// ...
},
);

In a similar fashion, when remote.getGlobal(name) is called, a remote-get-global event is raised. This works the same way as the remote-require event: call preventDefault() to prevent the global from being returned, and set event.returnValue to return a custom value.

// Control `remote.getGlobal` from all WebContents:
app.on(
'remote-get-global',
function (event, webContents, requrestedGlobalName) {
// ...
},
);

// Control `remote.getGlobal` from a specific WebContents instance:
browserWin.webContents.on(
'remote-get-global',
function (event, requestedGlobalName) {
// ...
},
);

For more information, see the following documentation:

JavaScript Access to the About Panel

On macOS, you can now call app.showAboutPanel() to programmatically show the About panel, just like clicking the menu item created via {role: 'about'}. See the showAboutPanel documentation for more information

Controlling WebContents Background Throttling

WebContents instances now have a method setBackgroundThrottling(allowed) to enable or disable throttling of timers and animations when the page is backgrounded.

let win = new BrowserWindow(...)
win.webContents.setBackgroundThrotling(启用BackgroundThrottling)
win.webContents.setBackgroundThrottling(enableBackgroundThrottling)

See the setBackgroundThrottling documentation for more information.

重大更改

No More macOS 10.9 Support

Chromium no longer supports macOS 10.9 (OS X Mavericks), and as a result Electron 4.0 and beyond does not support it either.

Single Instance Locking

Previously, to make your app a Single Instance Application (ensuring that only one instance of your app is running at any given time), you could use the app.makeSingleInstance() method. Starting in Electron 4.0, you must use app.requestSingleInstanceLock() instead. The return value of this method indicates whether or not this instance of your application successfully obtained the lock. If it failed to obtain the lock, you can assume that another instance of your application is already running with the lock and exit immediately.

For an example of using requestSingleInstanceLock() and information on nuanced behavior on various platforms, see the documentation for app.requestSingleInstanceLock() and related methods and the second-instance event.

win_delay_load_hook

When building native modules for windows, the win_delay_load_hook variable in the module's binding.gyp must be true (which is the default). If this hook is not present, then the native module will fail to load on Windows, with an error message like Cannot find module. See the native module guide for more information.

Deprecations

The following breaking changes are planned for Electron 5.0, and thus are deprecated in Electron 4.0.

Node.js Integration Disabled for nativeWindowOpen-ed Windows

Starting in Electron 5.0, child windows opened with the nativeWindowOpen option will always have Node.js integration disabled.

webPreferences Default Values

When creating a new BrowserWindow with the webPreferences option set, the following webPreferences option defaults are deprecated in favor of new defaults listed below:

PropertyDeprecated DefaultNew Default
contextIsolationfalsetrue
nodeIntegrationtruefalse
webviewTagvalue of nodeIntegration if set, otherwise truefalse

Please note: there is currently a known bug (#9736) that prevents the webview tag from working if contextIsolation is on. Keep an eye on the GitHub issue for up-to-date information!

Learn more about context isolation, Node integration, and the webview tag in the Electron security document.

Electron 4.0 will still use the current defaults, but if you don't pass an explicit value for them, you'll see a deprecation warning. To prepare your app for Electron 5.0, use explicit values for these options. See the BrowserWindow docs for details on each of these options.

webContents.findInPage(text[, options])

The medialCapitalAsWordStart and wordStart options have been deprecated as they have been removed upstream.

应用反馈项目

The App Feedback Program we instituted during the development of Electron 3.0 was successful, so we've continued it during the development of 4.0 as well. We'd like to extend a massive thank you to Atlassian, Discord, MS Teams, OpenFin, Slack, Symphony, WhatsApp, and the other program members for their involvement during the 4.0 beta cycle. To learn more about the App Feedback Program and to participate in future betas, check out our blog post about the program.

接下来

在短期内,您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发,包括 Chromium、Node 和 V8。 尽管我们谨慎地避免对发布日期做出承诺,但我们的计划是大约每季度发布一次 Electron 的新主要版本以及这些组件的新版本。 关于 Electron 版本的更多详细信息,请看我们的 版本管理文档

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.