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

バージョン管理スキーム

以下に、1.x 戦略からのいくつかの大きな変更点を概説します。各変更は、開発者/メンテナーとアプリ開発者のニーズと優先順位を満たすことを目的としています。

1. SemVer 仕様の厳密な使用
2. semver に準拠した -beta タグの導入
3. 慣例的なコミットメッセージの導入
4. 明確に定義された安定化ブランチ
5. main ブランチはバージョンレスです。安定化ブランチのみにバージョン情報が含まれます

git ブランチングの仕組み、npm タグ付けの仕組み、開発者が何を見るべきか、変更をバックポートする方法について詳しく説明します。

SemVer

以下は、変更の種類を対応する SemVer カテゴリ (例: メジャー、マイナー、パッチ) に明示的にマッピングした表です。

メジャーバージョンインクリメント	マイナーバージョンインクリメント	パッチバージョンインクリメント
Electron の破壊的な API 変更	Electron の非破壊的な API 変更	Electron のバグ修正
Node.js のメジャーバージョンアップデート	Node.js のマイナーバージョンアップデート	Node.js のパッチバージョンアップデート
Chromium のバージョンアップデート		修正関連の chromium パッチ

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

ほとんどの Chromium アップデートは破壊的とみなされることに注意してください。バックポートできる修正は、パッチとしてチェリーピックされる可能性が高くなります。

安定化ブランチ

安定化ブランチは main と並行して実行されるブランチで、セキュリティまたは安定性に関連するチェリーピックされたコミットのみを受け入れます。これらのブランチが main にマージされることはありません。

Electron 8 以降、安定化ブランチは常に メジャー バージョンラインであり、$MAJOR-x-y (例: 8-x-y) というテンプレートに対して名前が付けられます。それ以前は、マイナー バージョンラインを使用して、$MAJOR-$MINOR-x (例: 2-0-x) という名前を付けていました。

サポートされているバージョンごとに 1 つずつ、複数の安定化ブランチを同時に存在させることができます。サポートされているバージョンの詳細については、Electron リリースドキュメントを参照してください。

古いラインは Electron プロジェクトではサポートされませんが、他のグループが所有権を取得し、独自の安定性とセキュリティの修正をバックポートすることができます。これは推奨しませんが、多くのアプリ開発者にとって生活が楽になることは認識しています。

ベータリリースとバグ修正

開発者は、どのリリースを使用するのが安全かを知りたがっています。一見無害な機能でも、複雑なアプリケーションにリグレッションを引き起こす可能性があります。同時に、固定バージョンにロックすることは危険です。なぜなら、バージョン以降に公開されたセキュリティパッチやバグ修正を無視することになるからです。私たちの目標は、package.json で次の標準の semver 範囲を許可することです。

• 2.0.0 リリースへの安定性またはセキュリティ関連の修正のみを許可するには、~2.0.0 を使用します。
• セキュリティとバグ修正だけでなく、非破壊的な合理的に安定した機能作業も許可するには、^2.0.0 を使用します。

2 番目のポイントで重要なのは、^ を使用するアプリでも、ある程度の安定性を期待できる必要があるということです。これを実現するために、SemVer では、特定のバージョンがまだ安全または安定していないことを示すプレリリース識別子を使用できます。

どちらを選択しても、破壊的な変更は Chromium の常なので、package.json のバージョンを定期的に更新する必要があります。

プロセスは次のとおりです

1. すべての新しいメジャーおよびマイナーリリースラインは、2.0.0-beta.1 のような SemVer プレリリースタグで示されるベータシリーズから開始されます。最初のベータ版以降、後続のベータ版リリースは、次のすべての条件を満たす必要があります。
   1. 変更は下位互換性のある API である (非推奨は許可されます)
   2. 安定性のタイムラインを満たすリスクが低い必要があります。
2. リリースがベータ版になった後に変更が必要になった場合は、それらを適用して、プレリリースタグをインクリメントします (例: 2.0.0-beta.2)。
3. 特定のベータリリースが一般的に安定していると見なされた場合は、バージョン情報のみを変更して、安定版ビルドとして再リリースされます (例: 2.0.0)。最初の安定版以降、すべての変更は下位互換性のあるバグ修正またはセキュリティ修正である必要があります。
4. リリースが安定した後で将来のバグ修正またはセキュリティパッチが必要になった場合は、それらを適用してパッチバージョンをインクリメントします (例: 2.0.1)。

具体的には、上記は次のことを意味します。

1. ベータサイクル 3 週目より前の非破壊的な API 変更は、それらの変更が中程度の副作用を引き起こす可能性がある場合でも問題ありません。
2. 既存のコードパスをそれ以外に変更しない機能フラグ付きの変更は、ベータサイクル中のほとんどのポイントで問題ありません。ユーザーはアプリでこれらのフラグを明示的に有効にできます。
3. ベータサイクル 3 週目以降に何らかの機能を追加することは、非常に正当な理由がない限り 👎 です。

メジャーおよびマイナーバージョンが上がるたびに、次のようなものが表示されると予想されます。

2.0.0-beta.1
2.0.0-beta.2
2.0.0-beta.3
2.0.0
2.0.1
2.0.2

図によるライフサイクルの例

• 最新の機能セットを含む新しいリリースブランチが作成されます。これは 2.0.0-beta.1 として公開されます。
• リリースブランチにバックポートできるバグ修正がマスターに入ってきます。パッチが適用され、新しいベータ版が 2.0.0-beta.2 として公開されます。
• ベータ版は一般的に安定していると見なされ、2.0.0 で非ベータ版として再度公開されます。
• その後、ゼロデイ攻撃が明らかになり、修正がマスターに適用されます。修正を 2-0-x ラインにバックポートして 2.0.1 をリリースします。

さまざまな SemVer 範囲が新しいリリースをどのように取得するかのいくつかの例

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

サポートされているすべてのリリースラインは、以前に main にマージされた修正をバックポートするための外部プルリクエストを受け入れますが、一部の古いサポートされているラインについてはケースバイケースになる場合があります。リリースラインのバックポートに関するすべての異議決定は、バックポート PR が提起された週の週次会議で、議題項目としてリリースワーキンググループによって解決されます。

機能フラグ

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

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

セマンティックコミット

すべてのプルリクエストは、慣例的なコミット仕様に従う必要があります。これは次のように要約できます。

• SemVer のメジャーバージョンを上げるコミットは、本文を BREAKING CHANGE: で始める必要があります。
• SemVer のマイナーバージョンを上げるコミットは、feat: で始める必要があります。
• SemVer のパッチバージョンを上げるコミットは、fix: で始める必要があります。

electron/electron リポジトリはスカッシュマージも強制しているため、プルリクエストのタイトルに正しいプレフィックスが付いていることを確認するだけで済みます。

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

• main ブランチの package.json には、常に次のメジャーバージョン X.0.0-nightly.DATE が含まれます。
• リリースブランチが main にマージされることはありません。
• リリースブランチの package.json には、正しいバージョンが含まれています。
• メジャーリリースのためのリリースブランチが作成されたらすぐに、main は次のメジャーバージョンに上げる必要があります（つまり、main は常に次の理論上のリリースブランチとしてバージョン管理されます）。

過去のバージョン管理 (Electron 1.X)

Electron バージョン < 2.0 は、SemVer 仕様に準拠していませんでした。メジャーバージョンはエンドユーザー API の変更に対応し、マイナーバージョンは Chromium のメジャーリリースに対応し、パッチバージョンは新機能とバグ修正に対応していました。これは機能のマージを行う開発者にとっては便利でしたが、クライアント向けアプリケーションの開発者にとっては問題が生じました。Slack、Teams、Skype、VS Code、GitHub Desktop などの主要アプリの QA テストサイクルは長く、安定性が強く求められる結果となります。バグ修正を吸収しようとしながら新機能を導入することには高いリスクがあります。

以下は 1.x 戦略の例です。

1.8.1 で開発されたアプリは、1.8.2 の機能を吸収するか、修正をバックポートして新しいリリースラインを維持しない限り、1.8.3 のバグ修正を取り入れることができません。