composer'dモジュールにコードの複数のバージョンを含め、インストールターゲットのMagentoバージョンに基づいて、どのバージョンをデプロイするかをcomposerに計算させると非常に便利です。
たとえば、Magento> 1.7の場合はtooltip、ネストされたgroupその他の最新の機能を含むsystem.xmlを使用しますが、古いバージョンのMagentoの場合は、それらの（互換性のない）宣言を含まない簡略版のファイルを使用します。
このアプローチは、標準モジュール構造の他の多数のファイルでも機能します。
composerデプロイメントのオプションはmap、modmanまたはpackage.xmlAFAIKで、いずれもターゲットシステムに関するインテリジェンスを持ちません。package.xmlオプションでは、変更することはほとんどありませんが、map可能性...
グレースフルデグラデーションアプローチの恩恵を受けるエクステンション開発者はたくさんいるようです。誰かがこれの回避策を見つけましたか？
回答:
回避策はありませんが、まだ問題ではありませんが、機能する提案があります。
1.x、古いMagentoバージョン（たとえば、最大1.6）との互換性のためのブランチと、より新しいバージョンのためのブランチを含めることができ2.xます。それに応じてバージョンタグを追加します。もちろん、必要な数のブランチを維持し、各Magentoバージョンに最適なコードを記述できますが、IMHOこれは努力する価値がなく、1つの「モダン」ブランチと1つの「レガシー」ブランチで十分です。それはあなた次第であり、「モダン」ブランチとの後方互換性をどこまで望んでいるか、それは最新のマイナーバージョンでさえありえます。次のようにMagentoの要件を追加します。
"require": {
"magento/magento-ce": "1.4-1.7"
}そして
"require": {
"magento/magento-ce": ">=1.8"
}これでマイナス面が出てきます。これは、完全な影響力がなくなった部分です。公式magento/magento-ceパッケージがないため、拡張機能のユーザーは、https：//github.com/firegento/magentoなどのコミュニティ管理ミラーからMagentoをインストールする可能性があります。 -ceまたは独自のリポジトリから。これらは、同じバージョンの「仮想」パッケージを置き換える必要がありmagento/magento-ceます（プレースホルダーself.versionがあるため、バージョンの更新ごとにcomposer.jsonを調整する必要はありません）。
"replace": {
"magento/magento-ce": "self.version"
}これは、上記の規則が広く受け入れられている場合にのみ、また、おそらく大多数ではないcomposer依存関係を介してMagento自体を実際にインストールするユーザーに対してのみ機能します。
したがって、より現実的なアプローチは、ステップ1を実行し、ユーザーが1.xより古いMagentoバージョンを実行している場合は、異なるブランチ/異なるメジャーバージョンを要求するようにアドバイスすることです。