Magento 2：モジュールのcomposer.jsonで「セマンティックバージョニング」の依存関係を指定する方法

Magento 2の開発と導入にはバージョン管理の正式なプロセスが含まれます。コアMagentoモジュールのメジャーバージョンとマイナーバージョンは、下位互換性のある機能の変更に基づいて変更されます。

Magentoモジュールの開発者は、自分のcomposer.jsonファイルに要件のリストをどのように作成すればよいですか？コアMagentoコードを使用require:...してcomposer.jsonに行を追加するたびに、モジュールを手動で確認する必要がありますか？それとも私のためにそれを行うことができる自動化ツールはありますか？

含めるバージョンを指定するにはどうすればよいcomposer.jsonですか？それは私が開発した特定のモジュールバージョンである必要がありますか？それとも、何らかのワイルドカードが必要ですか？または、トレードオフに基づいて決定する必要がありますか？もしそうなら、バージョン指定の各スタイルに関連するトレードオフは何ですか？

この機能の概要はあちこちにありますが、実際の開発者が実際にどのような手順を踏む必要があるか、および/またはそれらの手順の実際の結果は不明です。

コアMagentoコードを使用するたびに手動でモジュールを確認し、require：...行をcomposer.jsonに追加する必要がありますか？

はい、コードでコアモジュールの何かを使用するたびに、それを作曲家の要求に追加する必要があります。ロードの順序をコアモジュールの後にしたいと思うのでmodule.xml、シーケンスセクションのファイルに追加することをお勧めします。

それとも私のためにそれを行うことができる自動化ツールはありますか？

まだ出会っていません。あれば教えてください。かなり洗練されたツールである必要があり、かなりのテストカバレッジを必要とする可能性が高く、さまざまなバージョンのマトリックスを実行してワーキングセットを作成します。

composer.jsonに含めるバージョンを指定するにはどうすればよいですか？それは私が開発した特定のモジュールバージョンである必要がありますか？それとも、何らかのワイルドカードが必要ですか？または、トレードオフに基づいて決定する必要がありますか？もしそうなら、バージョン指定の各スタイルに関連するトレードオフは何ですか？

バージョン番号を定義するオプション

1. 100.0.2
   この特定のバージョンの場合にのみ機能します

2. 100.0.*
*ワイルドカードであり、任意のバージョン番号に置き換えることができ 100.0.0、100.0.1、...、100.0.120

3. ~100.0.2
   2だけなので上がることができ、ワイルドカードになり100.0.2、100.0.3、 ...、100.0.120

4. ^100.0.2
   いずれかが101まで解放することができますので100.0.2、100.0.3、...、100.1.0、100.2.5

オプション2〜4の場合、安定性設定で許可されていれば、次のようなバージョンも含まれます。 100.0.1-beta

実用

オプション1.）は最も注意深いものです。開発したバージョンがわかっていて、この特定のバージョンでの作業のみを受け入れます。モジュールは、そのバージョンの特定のモジュールと一緒にのみインストールできます。他のすべてのインストール/アップグレードの試みは失敗し、コンポーネントのインストール可能なセットが見つからないことを示すcomposerメッセージが表示されます。

オプション2.）オプション3.でカバーされているのと同じように、オプションではないと考えることができると思います。 ~100.0.0

オプション3.）新しい機能が導入されない限り互換性がある

オプション4.）重大な変更が導入されていない限り互換性がある

トレードオフ

1拡張機能はMagentoモジュールの1つのバージョンでのみ機能します（技術的にはモジュールに変更がない場合、バージョン番号は増加せず、理論的には複数のMagento Projectバージョンが同じバージョンの同じMagentoコアモジュールを含む可能性があります。これを見たことがないので、Magento側でプロセスを変更する必要があるようです（こちらを参照）。Magentoコアモジュールの1つのバージョンと密接に結びついているため、互換性を維持したい場合は、多くのリリースと独自の拡張機能のバージョンが必要になります。

3-4拡張はMagentoの複数のバージョンで動作し、Magentoが新しいバージョンをリリースするたびに拡張の異なるバージョンをリリースする必要はありません。ここでの欠点は、自分のコードと互換性のない変更がMagentoに導入されたとしても、互換性を主張することです。Magentoの独自のモジュールリリースのセマンティックバージョニングの定義は、範囲が限定された@api注釈（このGitHubの問題の詳細）でマークされたものにのみ拡張されるため、このリスクは本当です。

tl; dr; セマンティックバージョニングがどのように機能するか
100.0.2を維持するために、多くのリリースを安全にプレイし
^100.0.2てください@api。認可されたクラスとメソッドを使用して100％の拡張がある場合、これは当然の選択です。

それ0.1.0-alpha1 -> 0.1.0-alpha2, 0.1.0-alpha3,は、モジュールの安定性に基づくようなものです。ドキュメントで共有されているように、要件は次のようになります：-

"require": {
    "myexamplestore/product-bundle": "2.0.0-RC1",
    "myexamplestore/acme-extension": "~1.0"
    }

更新に基づいて、これは次のように更新する必要があります：-

"require": {
    "myexamplestore/product-bundle": "2.4.0-RC1",
    "myexamplestore/acme-extension": "~2.0"
    }

私はまだこれに自動化されたシステムがあるとは思いませんが、ドキュメントによると、これに従うことは非常に重要です。

ただし、モジュールに小さなバグ修正がある場合は、PATCHを使用する必要があります。

参照する

PATCHは下位互換性のあるバグ修正を示します

正解は少しわかりにくいですが、約1年前に更新されたことがわかります。しかし、これはそうです。