Electronのバージョン管理

バージョン管理ポリシーと実装の詳細をご覧ください。

バージョン 2.0.0 から、Electron は SemVer 仕様に準拠しています。 以下のコマンドで、最新の安定版 Electron のビルドをインストールできます。

npm

npm install --save-dev electron

Yarn

yarn add --dev electron

既存のプロジェクトを最新の安定版を使用するように更新するには、以下のようにします。

npm

npm install --save-dev electron@latest

Yarn

yarn add --dev electron@latest

SemVer

以下は、変更の種別をそれに対応する SemVer のカテゴリ (メジャー、マイナー、パッチなど) へ明示的に割り当てた表です。

メジャーバージョンの単位	マイナーバージョンの単位	パッチバージョンの単位
互換性を破る Electron API の変更	互換性を破らない Electron API の変更	Electron のバグ修正
Node.js のメジャーバージョン更新	Node.js のマイナーバージョン更新	Node.js のパッチバージョン更新
Chromium のバージョン更新		fix-related Chromium patches

詳細については、「セマンティックバージョニング 2.0.0」をご参照ください。

注意として、ほとんどの Chromium のアップデートは破壊的とみなされます。 バックポート可能な修正は、パッチとしてチェリーピックされます。

安定化ブランチ

安定化ブランチは、セキュリティまたは安定性に関連する cherry-pick されたコミットのみを取り入れて、main と並行して走るブランチです。 これらのブランチは main にマージし戻すことはありません。

Electron 8 以降、安定化ブランチは常に major のバージョンラインであり、テンプレート $MAJOR-x-y に沿って 8-x-y のように名前を付けます。 (Prior to that, we used minor version lines and named them as $MAJOR-$MINOR-x e.g. 2-0-x.)

複数の安定化ブランチは同時に存在でき、サポートするバージョンごとに 1 つずつ存在します。

[!TIP] For more details on which versions are supported, see our Electron Releases doc.

Older lines will not be supported by the Electron project.

Release cycle

Electron follows an 8-week regular release cycle where key milestones correspond to matching dates in the Chromium release cycle.

サンプル

When Electron 41 hits its stable release, the release line for Electron 42 is branched off of main. Its first alpha release is created with all the changes contained on main:

A bug fix comes into main that can be backported to the release branch. The patch is applied, and it is published in the next v42.0.0-alpha.2 release.

The version of Chromium that powers Electron 42 hits Chrome's beta channel. The alpha line is promoted to beta.

Beta releases continue weekly until Electron 42 is promoted to stable and the same cycle starts again with 43-x-y. Later, a zero-day exploit is revealed and a fix is applied to main. We backport the fix to the 42-x-y line and release 42.0.1.

バックポートのリクエストプロセス

サポートされているすべてのリリースラインは、以前 main にマージされた修正をバックポートする外部のプルリクエストを受け付けます。これは、一部の古いサポートラインではケースバイケースとなります。 すべてのリリースラインのバックポートに関する紛糾は、バックポートのプルリクエストが発行された週に、週一回の会議での議題項目として リリースワーキンググループ によって解決されます。

機能フラグ

機能フラグは Chromium で一般的な方法であり、Web 開発エコシステムではよく確立されています。 Electron のコンテキストでは、機能フラグまたは ソフトブランチ には次のプロパティが必要です。

• 実行時またはビルド時に有効/無効になるもの。リクエストスコープ付き機能フラグの概念はサポートしていない
• 新旧のコードパスを完全に断片化するもの。 新しい機能をサポートするために古いコードをリファクタリングすると機能フラグ規約に 違反する
• 機能のリリース後、機能フラグは最終的に削除される

セマンティックなコミット

すべてのプルリクエストは、Conventional Commits 仕様に従わなければなりません。この仕様は、以下のように要約できます。

• major バージョンを上げるコミットの本文は BREAKING CHANGE: で始まる必要があります。
• minor バージョンを上げるコミットは feat: で始まる必要があります。
• patch バージョンを上げるコミットは fix: で始まる必要があります。

electron/electron リポジトリではスカッシュマージの強制も行われているので、プルリクエストのタイトルの接頭辞が正しいことを確認するだけでよいのです。

バージョン管理された main ブランチ

• The main branch always corresponds to the major version above the current pre-release line.
• Unstable nightly releases of main are released under the electron-nightly package on npm.
• リリースブランチは main にマージし戻すことはありません。
• All package.json values are fixed at 0.0.0-development.

かつてのバージョン管理 (Electron 1.X)

Electron 2.0 より前のバージョンでは SemVer の仕様に準拠していませんでした。メジャーバージョンはエンドユーザ API の変更に、マイナーバージョンは Chromium のメジャーリリースに、パッチバージョンは新機能やバグ修正に対応していました。 機能を統合する開発者にとっては便利ですが、クライアント向けアプリケーションの開発者には問題が生じます。 The QA testing cycles of major apps like Slack, Teams, VS Code, and GitHub Desktop can be lengthy and stability is a highly desired outcome. これは、バグ修正を吸収しようとする一方で、新しい機能を採用することに高いリスクがあります。

1.x の方針の例を以下に示します。

1.8.1 を使用して開発されたアプリケーションは、1.8.2 の機能を取り入れるか、修正をバックポートし、新しいリリースラインをメンテナンスすることなしに、1.8.3 のバグ修正をとることもできません。