メインコンテンツへ飛ぶ

Electronのバージョン管理

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

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

npm install --save-dev electron

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

npm install --save-dev electron@latest

バージョン管理スキーム​

上に概説されている 1.x の方針から、いくつかの大きな変更があります。 各変更は、開発者/管理者とアプリ開発者のニーズと優先順位を満たすためのものです。

  1. SemVer 仕様の厳密な利用
  2. semver 準拠の -beta タグの導入
  3. conventional commit messages の導入
  4. しっかり定義された安定ブランチ
  5. main ブランチにはバージョンがなく、安定ブランチのみがバージョン情報を含みます。

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

SemVer​

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

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

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

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

安定化ブランチ​

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

安定ブランチ

Electron 8 以降、安定化ブランチは常に major のバージョンラインであり、テンプレート $MAJOR-x-y に沿って 8-x-y のように名前を付けます。 以前は minor のバージョンラインを使用しており、$MAJOR-$MINOR-x に沿って 2-0-x のような名前にしていました。

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

複数の安定化ブランチ

古いリリースラインは GitHub ではサポートされませんが、他のグループが所有権を持って、自分自身で安定性とセキュリティの修正をバックポートできます。 これはお勧めできませんが、多くのアプリ開発者にとってライフが楽になると認識しています。

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

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

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

2つ目の点に関して重要なことは、^ を使用しているアプリはまだ妥当なレベルの安定性を期待できることです。 これを実現するために、SemVer では特定のバージョンがまだ 安全 または 安定 ではないことを示す プレリリース識別子 を指定できるようになっています。

どれを選択しても、破壊的な変更は Chromium が寿命である事実であるため、定期的に package.json 内のバージョンを更新する必要があります。

プロセスは以下の通りです。

  1. すべての新しいメジャーリリースラインとマイナーリリースラインは、2.0.0-beta.1 のような beta.N の SemVer プレリリースタグで示されたベータ系列で始めます。 最初のベータ版の後、その後のベータ版リリースは以下のすべての条件を満たす必要があります。
    1. 変更は API に後方互換性がある (非推奨は構いません)
    2. 安定版のスケジュールを守るリスクが低くなければならない。
  2. リリースがベータ版になった後に許可された変更を加える必要がある場合は、それらが適用され、例として 2.0.0-beta.2 のようにプレリリースタグが増分されます。
  3. 特定のベータリリースが 一般的に安定している と見なされている場合、バージョン情報のみを変更して、安定したビルドとして再リリースされます。 例として、2.0.0 のようになります。 最初の安定版以降は、すべての変更は後方互換性のあるバグまたはセキュリティ修正でなければなりません。
  4. リリースが安定した後に将来のバグ修正やセキュリティパッチを作成する必要がある場合は、それらを適用して、例として 2.0.1 のように、patch のバージョンを増やします。

具体的に言うと、以下が上記の意味です。

  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 範囲で新リリースを取得する例をいくつか示します。

semver とリリース

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

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

機能フラグ​

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

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

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

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

  • major バージョンを上げるコミットの本文は BREAKING CHANGE: で始まる必要があります。
  • minor バージョンを上げるコミットは feat: で始まる必要があります。
  • patch バージョンを上げるコミットは 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、Atom、GitHub Desktop などのメジャーなアプリの QA テストサイクルは時間がかかることがあり、安定性においては非常に望ましい結果を出します。 これは、バグ修正を吸収しようとする一方で、新しい機能を採用することに高いリスクがあります。

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

1.x バージョン管理

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