Bei Bedarf werden Tages- und andere wichtige sicherheitsrelevante Veröffentlichungen veröffentlicht. Sicherheitsvorfälle sollten über SECURITY.md gemeldet werden.
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. Alle freuen sich auf 2023, und wir erwarten gute Dinge! Wir ermutigen andere Projekte, ähnliche Maßnahmen in Erwägung zu ziehen.
Wir freuen uns bekanntgeben zu können, dass Electron Forge v6.0.0 jetzt verfügbar ist! This release marks the first major release of Forge since 2018 and moves the project from electron-userland into the main electron organization on Github.
Keep on reading to see what's new and how your app can adopt Electron Forge!
Electron Forge ist ein Werkzeug zum Verpacken und Verteilen von Electron-Anwendungen. It unifies Electron's build tooling ecosystem into a single extensible interface so that anyone can jump right into making Electron apps.
Highlight features include:
📦 Application packaging and code signing
🚚 Customizable installers on Windows, macOS, and Linux (DMG, deb, MSI, PKG, AppX, etc.)
From v1 to v5, Electron Forge was based on the now-discontinued electron-compile project. Forge 6 is a complete rewrite of the project with a new modular architecture that can be extended to meet any Electron application's needs.
In the past few years, Forge v6.0.0-beta has achieved feature parity with v5 and code churn has slowed down dramatically, making the tool ready for general adoption.
Don't install the wrong package
For versions 5 and below, Electron Forge was published to the electron-forge package on npm. Starting with the v6 rewrite, Forge is instead structured as a monorepo project with many smaller projects.
Historically, Electron maintainers have been unopinionated about build tooling, leaving the task to various community packages. However, with Electron maturing as a project, it has become harder for new Electron developers to understand which tools they need to build and distribute their apps.
To help guide Electron developers in the distribution process, we have have decided to make Forge the official batteries-included build pipeline for Electron.
Over the past year, we have been slowly integrating Forge into the official Electron documentation, and we have recently moved Forge over from its old home in electron-userland/electron-forge to the electron/forge repo. Now, we are finally ready to release Electron Forge to a general audience!
Scaffolding a new Electron Forge project can be done using the create-electron-app CLI script.
Yarn
npm
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
The script will create an Electron project in the my-app folder with completely JavaScript bundling and a preconfigured build pipeline.
For more info, see the Getting Started guide in the Forge docs.
First-class webpack support
The above snippet uses Forge's Webpack Template, which we recommend as a starting point for new Electron projects. This template is built around the @electron-forge/plugin-webpack plugin, which integrates webpack with Electron Forge in a few ways, including:
enhancing local dev flow with webpack-dev-server, including support for HMR in the renderer;
handling build logic for webpack bundles before application packaging; and
adding support for Native Node modules in the webpack bundling process.
When you use the import command, Electron Forge will add a few core dependencies and create a new forge.config.js configuration. If you have any existing build tooling (e.g. Electron Packager, Electron Builder, or Forge 5), it will try to migrate as many settings as possible. Some of your existing configuration may need to be migrated manually.
If you already have tooling for packaging and publishing your Electron app, the benefits associated with adopting Electron Forge can still outweigh the initial switching cost.
We believe there are two main benefits to using Forge:
Forge receives new features for application building as soon as they are supported in Electron. In this case, you won't need to wire in new tooling support yourself, or wait for that support to be eventually implemented by other packages before upgrading. For recent examples, see macOS universal binaries and ASAR integrity checking.
Forge's multi-package architecture makes it easy to understand and extend. Since Forge is made up of many smaller packages with clear responsibilities, it is easier to follow code flow. In addition, Forge's extensible API design means that you can write your own additional build logic separate from the provided configuration options for advanced use cases. For more details on writing custom Forge plugins, makers, and publishers, see the Extending Electron Forge section of the docs.
Forge 6 has spent a long time in the beta phase, and its release cadence has gradually slowed down. However, we have accelerated development in the second half of 2022 and used the last few releases to push some final breaking changes before the v6.0.0 stable release.
If you are an Electron Forge 6 beta user, see the v6.0.0 GitHub release notes for a list of breaking changes made in recent betas (>=6.0.0-beta.65).
A complete list of changes and commits can be found in the repo's CHANGELOG.md.
Tell us what you need! The Electron Forge team is always looking to build the project to better suit its users.
You can help us improve Electron Forge by submitting feature requests, posting issues, or just letting us know your feedback! You can also join us in the official Electron Discord server, where there is a dedicated channel for Electron Forge discussion.
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!
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!
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.
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.
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.
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!
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.
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!
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.0.0 wurde veröffentlicht! Es enthält Upgrades auf Chromium 106, V8 10.6 und Node.js 16.16.0. Lesen Sie unten für weitere Details!
Das Electron-Team freut sich über die Veröffentlichung von Electron 21.0.0! Sie können es mit npm über npm install electron@latest installieren oder von unserer Release-Website herunterladen. Lesen Sie weiter für Details zu dieser Version.
Wenn du ein Feedback hast, teile es bitte mit uns auf Twitter, oder trete unserer Community Discord bei! Bugs und Feature-Requests können in Electrons Issue-Tracker gemeldet werden.
Electron 21 aktiviert V8 Sandboxed Pointernach der Entscheidung von Chrome das Gleiche in Chrome 103 zu tun. This has some implications for native modules. Diese Funktion hat Performance- und Sicherheitsvorteile, aber auch einige neue Einschränkungen für native Module, z.B. Verwendung von ArrayBuffers, die auf einen externen ("off-heap") Speicher verweisen. Bitte sehen Sie diesen Blog-Beitrag für weitere Informationen. #34724
Electron 18.x.y hat das Ende der Unterstützung gemäß der Unterstützungsrichtlinien des Projekts erreicht. Developers and applications are encouraged to upgrade to a newer version of Electron.
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.
Sie finden die öffentliche Timeline von Electron hier.
Weitere Informationen über zukünftige Änderungen finden Sie auf der geplante Änderungen Seite.
Electron 20.0.0 wurde veröffentlicht! Es enthält Upgrades auf Chromium 104, V8 10.4und Node.js 16.15.0. Lesen Sie unten für weitere Details!
Das Electron Team freut sich über die Veröffentlichung von Electron 20.0.0! Sie können es mit npm über npm install electron@latest installieren oder von unserer Release-Website herunterladen. Lesen Sie weiter für Details zu dieser Veröffentlichung und teilen Sie bitte alle Rückmeldungen, die Sie haben!
Im Folgenden finden Sie die in Electron 20 eingeführten großen Änderungen. Weitere Informationen zu diesen und zukünftigen Änderungen finden Sie auf der geplante Änderungen Seite.
Default Changed: renderers without nodeIntegration: true are sandboxed by default
Previously, renderers that specified a preload script defaulted to being unsandboxed. This meant that by default, preload scripts had access to Node.js. In Electron 20, this default has changed. Beginning in Electron 20, renderers will be sandboxed by default, unless nodeIntegration: true or sandbox: false is specified.
If your preload scripts do not depend on Node, no action is needed. If your preload scripts do depend on Node, either refactor them to remove Node usage from the renderer, or explicitly specify sandbox: false for the relevant renderers.
Fixed: spontaneous crashing in nan native modules
In Electron 20, we changed two items related to native modules:
V8 headers now use c++17 by default. This flag was added to electron-rebuild.
We fixed an issue where a missing include would cause spontaneous crashing in native modules that depended on nan.
For the most stability, we recommend using node-gyp >=8.4.0 and electron-rebuild >=3.2.9 when rebuilding native modules, particularly modules that depend on nan. See electron #35160 and node-gyp #2497 for more information.
On X11, skipTaskbar sends a _NET_WM_STATE_SKIP_TASKBAR message to the X11 window manager. There is not a direct equivalent for Wayland, and the known workarounds have unacceptable tradeoffs (e.g. Window.is_skip_taskbar in GNOME requires unsafe mode), so Electron is unable to support this feature on Linux.
Electron 17.x.y hat das Ende der Unterstützung gemäß der -Unterstützungsrichtlinien des Projekts erreicht. Developers and applications are encouraged to upgrade to a newer version of Electron.
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. Obwohl wir darauf achten, keine Versprechungen über Veröffentlichungstermine zu machen, unser Plan ist es, neue Hauptversionen von Electron mit neuen Versionen dieser Komponenten ungefähr alle 2 Monate freizugeben.
Sie finden die öffentliche Timeline von Electron hier.
Weitere Informationen über zukünftige Änderungen finden Sie auf der geplante Änderungen Seite.
Electron 21 and later will have the V8 Memory Cage enabled, with implications for some native modules.
Update (2022/11/01)
To track ongoing discussion about native module usage in Electron 21+, see electron/electron#35801.
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:
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.
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.
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?
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:
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.
Abuse this confusion to overwrite some bit of memory inside the V8 heap, for instance, the pointer to the beginning of an ArrayBuffer.
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.
I want to refactor a Node native module to support Electron 21+. How do I do that?
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 19.0.0 wurde veröffentlicht! Es enthält Upgrades auf Chromium 102, V8 10.2und Node.js 16.14.2. Lesen Sie unten für weitere Details!
Das Electron Team freut sich über die Veröffentlichung von Electron 19.0.0! Sie können es mit npm über npm install electron@latest installieren oder von unserer Release-Website herunterladen. Lesen Sie weiter für Details zu dieser Veröffentlichung und teilen Sie bitte alle Rückmeldungen, die Sie haben!
Das Projekt kehrt zu seiner früheren Politik zurück, die letzten drei Hauptversionen zu unterstützen. Lesen Sie unser Versionierungsdokument für detailliertere Informationen über Electron-Versionierung und Support. Dies waren vorübergehend vier Hauptversionen zur Anpassung an die neue Release-Kadenz, die in Electron 15 begann. Lesen Sie die Details hier.
Im Folgenden finden Sie die in Electron 19 eingeführten großen Änderungen. Weitere Informationen zu diesen und zukünftigen Änderungen finden Sie auf der geplante Änderungen Seite.
Elektron 14.x.y und 15.x.y haben beide das Ende der Unterstützung erreicht. Dieses führt Electron zu seiner bestehenden Richtlinie zurück, die die letzten drei Hauptversionen unterstützt. Developers and applications are encouraged to upgrade to a newer version of Electron.
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. Obwohl wir darauf achten, keine Versprechungen über Veröffentlichungstermine zu machen, unser Plan ist es, neue Hauptversionen von Electron mit neuen Versionen dieser Komponenten ungefähr alle 2 Monate freizugeben.
Sie finden die öffentliche Timeline von Electron hier.
Weitere Informationen über zukünftige Änderungen finden Sie auf der geplante Änderungen Seite.
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:
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.
Electron 18.0.0 wurde veröffentlicht! Es enthält Upgrades auf Chromium 100, V8 10.0und Node.js 16.13.2. Lesen Sie unten für weitere Details!
Das Electron Team freut sich über die Veröffentlichung von Electron 18.0.0! Sie können es mit npm über npm install electron@latest installieren oder von unserer Release-Website herunterladen. Lesen Sie weiter für Details zu dieser Veröffentlichung und teilen Sie bitte alle Rückmeldungen, die Sie haben!
Ab Electron 15 wird Electron alle 8 Wochen eine neue stabile Version veröffentlichen. Lesen Sie die Details hier.
Zusätzlich hat Electron die unterstützte Version von den letzten drei Versionen auf die letzten vier Versionen bis Mai 2022 geändert. Lesen Sie unser Versionierungsdokument für detailliertere Informationen über Versionierung in Electron. Nach Mai 2022 werden wir wieder zu den neuesten drei Versionen zurückkehren.
ses.setCodeCachePath() API zum Setzen des Code-Cache-Verzeichnisses hinzugefügt. #33286
Die alte BrowserWindowProxy basierte Implementierung von window.open entfernt. Dies entfernt auch die nativeWindowOpen Option von webPreferences. #29405
'focus' und 'blur' Ereignisse zu WebContents hinzugefügt. #25873
Ersetzungsmenürollen auf macOS hinzugefügt: showSubstitutions, toggleSmartQuotes, toggleSmartDashes, toggleTextReplacement. #32024
Added a first-instance-ack event to the app.requestSingleInstanceLock() flow, allowing users to seamlessly transmit data from the first instance to the second instance. #31460
Unterstützung für weitere Farbformate in setBackgroundColor hinzugefügt. #33364
Eine vollständige Liste der neuen Funktionen und Änderungen finden Sie in den 18.0.0 Versionshinweise.
Im Folgenden finden Sie die in Electron 18 eingeführten großen Änderungen. Weitere Informationen zu diesen und zukünftigen Änderungen finden Sie auf der geplante Änderungen Seite.
Prior to Electron 15, window.open was by default shimmed to use BrowserWindowProxy. Dies bedeutete, dass window.open('about:blank') nicht funktioniert hat, um synchron Skriptfenster, neben anderen Inkompatibilitäten, zu öffnen. Seit Electron 15 ist nativeWindowOpen standardmäßig aktiviert.
Electron 14.x.y hat das Ende der Unterstützung gemäß der -Unterstützungsrichtlinien des Projekts erreicht. Developers and applications are encouraged to upgrade to a newer version of Electron.
Ab Electron 15 haben wir die unterstützte Version von den letzten drei Versionen auf die letzten vier Versionen bis Mai 2022 mit Electron 19 geändert. Nach Electron 19 werden wir wieder die letzten drei Versionen unterstützen. Diese Versions-Unterstützungs-Veränderung ist Teil unserer neuen Kadenz Änderung. Bitte sehen Sie in unseren Blog-Beitrag für alle Details hier.
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. Obwohl wir darauf achten, keine Versprechungen über Veröffentlichungstermine zu machen, unser Plan ist es, neue Hauptversionen von Electron mit neuen Versionen dieser Komponenten ungefähr alle 2 Monate freizugeben.
Sie finden die öffentliche Timeline von Electron hier.
Weitere Informationen über zukünftige Änderungen finden Sie auf der geplante Änderungen Seite.
Google Summer of Code (GSoC) ist ein jährliches Mentoring-Programm, das Open-Source-Software-Projekte mit potenziellen Mitwirkenden verbindet. Früher nur für Studierende geöffnet, können sich jetzt alle ab 18 Jahren bei GSoC registrieren.
Sind Sie an einer Zusammenarbeit mit Electronic interessiert? Wenn Sie ein neuer oder Anfänger von Open-Source-Mitwirkender sind, freuen wir uns über Ihre Bewerbung!
Möchtest du dich bewerben? Schauen Sie sich zuerst die fünf Projektideen an, die wir vorbereitet haben. Alle aufgeführten Ideen sind derzeit offen für Vorschläge. Wir sind auch bereit, neue Ideen zu akzeptieren, die nicht auf der vorgeschlagenen Projektliste stehen.
Ihre Bewerbung sollte beinhalten:
Ihr Vorschlag, das ist ein schriftliches Dokument, das genau beschreibt, was Sie im Laufe des Sommers zu erreichen gedenken.
Dein Hintergrund als Entwickler. Wenn Sie einen Lebenslauf haben, geben Sie bitte ein Exemplar an, sonst teilen Sie uns Ihre Erfahrungen mit einem Schwerpunkt auf relevante technische Erfahrung mit.
