Eine Electron-App hat drei Versions-Komponenten: Electron selbst, die enthaltene Chromium-Version (für den Renderer) und die Node-Version (für den Main). Major-Releases gibt es alle 8 Wochen — und die genaue Kombination entscheidet, welche Web-APIs funktionieren und welche Node-Features verfügbar sind.
Die drei Versionen zur Laufzeit
console.log(process.versions.electron); // '32.2.0'
console.log(process.versions.chrome); // '128.0.6613.137'
console.log(process.versions.node); // '20.18.0'
console.log(process.versions.v8); // '12.8.374.32-electron.0'process.versions funktioniert sowohl im Main als auch im Renderer (auch im Sandbox-Modus über process im Preload zugänglich).
Versions-Mapping
Electron koppelt sich an Chromium und Node. Beispielhafte Zuordnung:
| Electron | Chromium | Node | Release |
|---|---|---|---|
| 28 | 120 | 18.18 | Dez 2023 |
| 29 | 122 | 20.9 | Feb 2024 |
| 30 | 124 | 20.11 | Apr 2024 |
| 31 | 126 | 20.14 | Jun 2024 |
| 32 | 128 | 20.18 | Aug 2024 |
| 33 | 130 | 20.18 | Okt 2024 |
Die genaue aktuelle Tabelle: electronjs.org/docs/latest/tutorial/electron-timelines.
Wichtig: ältere Beispiele aus dem Web können nodeIntegration: true zeigen, weil sie für Electron 4–11 geschrieben sind. Modern arbeitet anders. Versions-Hinweis im Code-Beispiel beachten.
Release-Kadenz
Electron synchronisiert grob mit Chromium:
- Neuer Major alle 8 Wochen (gleich Chromium-Release)
- Pro Major Patch-Releases mit Bugfixes und Security
- Support für 3 Major-Versionen parallel — danach EOL
- EOL-Versions bekommen keine Sicherheits-Updates mehr
Heißt: bei Electron 32 als „latest" sind 30, 31, 32 supported. 29 und älter sind EOL.
Pragmatisch: alle 6–9 Monate Major-Update planen — sonst läufst du in EOL und damit in fehlende Security-Patches.
Welche Version für neue Projekte?
Empfehlung: aktuelle stable Major-Version oder die direkt davor. Niemals Beta/Nightly für Production.
{
"devDependencies": {
"electron": "^32.0.0"
}
}Caret (^) erlaubt Patch- und Minor-Updates, keine Majors — sicherer Standard.
Wer langfristig stabilisieren will: feste Major-Version ("electron": "32.2.1") und manuell hochziehen.
Major-Upgrade — der typische Aufwand
Bei einem Major-Upgrade prüfen:
- Breaking Changes in Release-Notes durchgehen
- Deprecation Warnings — schon vor dem Upgrade adressieren
- Native Modules —
electron-rebuildausführen, sonst crashen sie - Tests laufen lassen — Renderer und Main
- Manuelle Smoke-Tests auf allen Plattformen
# Electron-Version aktualisieren
npm install --save-dev electron@latest
# Native Modules neu bauen
npx electron-rebuild
# Test
npm run develectron-rebuild ist Pflicht bei jedem Major-Update, wenn du native Module wie better-sqlite3, sharp, node-pty o. ä. verwendest. Ohne das passt das ABI nicht — App crasht beim Laden.
Versions-Detection im Code
Wer Code für mehrere Electron-Versions pflegt:
const electronMajor = parseInt(process.versions.electron.split('.')[0]);
if (electronMajor >= 28) {
// ESM-Preload-Skripte verfügbar
}
if (electronMajor >= 32) {
// Notarization-Workflow neu seit Apple-Änderungen
}In neuen Apps eher selten — wer eine bestimmte Min-Version requires, kann in package.json setzen:
{
"engines": {
"electron": ">=30.0.0"
}
}App-Version vs. Electron-Version
Wichtig nicht verwechseln:
| Wo | |
|---|---|
| App-Version | package.json version-Field — was deine User in „About" sehen |
| Electron-Version | package.json devDependencies — Runtime-Bundle |
| Chromium / Node | aus Electron abgeleitet, nicht direkt setzbar |
App-Version mit app.getVersion() zur Laufzeit auslesen. Die anderen via process.versions.
Interessantes
Chromium-Version entscheidet über verfügbare Web-APIs.
Wenn ein Web-API in Electron 28 nicht funktioniert: prüfen, welche Chromium-Version das ist, und auf caniuse.com gegenchecken. Polyfills sind manchmal nötig — oder Upgrade auf neuere Electron-Version.
Electron-Major alle 8 Wochen — schneller als Node.
Electron-Tempo ist Chromium-getaktet, nicht Node-getaktet. Deine Node-Major-Version bewegt sich seltener — z. B. Electron 28-32 alle mit Node 18 oder 20, kein Wechsel. Aber: wenn Electron einen Node-Wechsel macht, ist das oft ein Breaking-Punkt für native Module.
electron-rebuild ist Pflicht bei nativen Modulen.
Native Module sind gegen ein bestimmtes ABI kompiliert. Electron bringt sein eigenes mit. Ohne Rebuild beim Major-Update: App crasht. Mit Forge/Builder oft automatisiert; bei plain npm manuell.
Beta-Releases sind testbar, nicht für Production.
Electron veröffentlicht Beta vor jedem Major. Nützlich, um Apps schon zu testen. Nicht für Distribution — ist instabil und supported nicht.
EOL-Versionen kein Spielzeug.
Wer auf einer EOL-Version sitzen bleibt, bekommt keine Security-Patches mehr. Auf macOS und Windows wird das durch Code-Signing/Notarization-Anforderungen oft ohnehin erzwungen — Apple verlangt regelmäßig neue Notarization-Submissions.
Versions-Hinweis im Doku-Artikel = Pflicht.
Wenn ein Code-Beispiel ESM nutzt (import im Preload), Hinweis: „ab Electron 28". Wenn WebContentsView statt BrowserView: „ab Electron 28". Sonst frustrieren Beispiele User mit alten Electron-Versions.
Weiterführende Ressourcen
Externe Quellen
- Electron Releases Timeline
- Electron Releases — alle Versions mit Chromium/Node-Mapping
- Electron Blog — Major-Release-Notes
- Breaking Changes — kuratierte Liste pro Version
- electron-rebuild