Ground Sunlight

Windowsで作る - PHPプログラミングの開発環境

ユーザ用ツール

サイト用ツール


サイドバー

メインメニュー

XAMPP アレンジ

IED

WSL2

道具箱

リポジトリ編

フレームワーク編

公開ソフトウェア

メタ
リンク


このページへのアクセス
今日: 1 / 昨日: 2
総計: 1895

composer:1.9:version-constraints

文書の過去の版を表示しています。


Composer バージョン制約

Version 1.9.1

y2sunlight 2020-03-16

Composer に戻る

関連記事

本章は以下のページの翻訳に補足事項を加筆をしたものです。

Versions and constraints — https://getcomposer.org/doc/articles/versions.md


ComposerバージョンとVCSバージョン

ComposerはgitなどのVCS(バージョン管理システム)の利用に重点を置いているため、「バージョン」という用語は少し曖昧な場合があります。バージョン管理システムの意味では、「バージョン」は特定のデータを含む特定のファイルセットのことです。gitの用語では、これは ref または特定のコミットであり、ブランチHEADまたはタグで表されます。あなたがVCSでそのバージョン(タグv1.1やコミットe35fa0dなど)をチェックアウトする時、単一で既知のファイルセットが要求され、常に同じファイルが返ってきます。

Composerでは、しばしば気軽にバージョンと呼ばれるもの、つまり、require でパッケージ名に続く文字列(例:~1.1 または 1.2.*)は、実際に、より具体的に言えば、それはバージョン制約のことです。Composerは、バージョン制約を使用して、VCSのどの ref をチェックアウトするかを判断します(また、composer.json のバージョン仕様で静的にメンテナンスされたライブラリの場合は、特定のライブラリが受け入れられることを確認します)。


VCS Tags and Branches

以下の説明では、次のサンプルライブラリのリポジトリを想定します。

~/my-library$ git branch
v1
v2
my-feature
another-feature

~/my-library$ git tag
v1.0
v1.0.1
v1.0.2
v1.1-BETA
v1.1-RC1
v1.1-RC2
v1.1
v1.1.1
v2.0-BETA
v2.0-RC1
v2.0
v2.0.1
v2.0.2

Tags

通常、Composerはタグを処理します。バージョン制約を記述するとき、特定のタグ(例:1.1)を参照する場合と、有効なタグ範囲(例:>= 1.1 <2.0 または ~4.0)を参照する場合があります。これらの制約を解決するために、ComposerはまずVCSに利用可能な全てのタグを一覧表示するように要求し、次にこれらのタグに基づいて利用可能なバージョンの内部リストを作成します。上記の例では、composerの内部リストには、バージョン1.01.0.11.0.21.1-BETA1.1のRC1版とRC2版、1.1の最終リリース版などが含まれています。(Composer有効な最終バージョン番号を取得するために、実際のタグ名の vプレフィックスを自動的に削除します。

ComposerがVCSで使用可能なバージョンの完全なリストを取得すると、Composerはプロジェクト内の全てのバージョン制約に一致する最上位バージョンを検索します(他のパッケージでは、より特定のバージョンのライブラリが必要になる可能性があるため、選択するバージョンは常に最高のバージョンであるとは限りません)、そして、そのタグのzipアーカイブをダウンロードして、vendor ディレクトリの正しい場所に解凍します。

Branches

If you want Composer to check out a branch instead of a tag, you need to point it to the branch using the special dev-* prefix (or sometimes suffix; see below). If you're checking out a branch, it's assumed that you want to work on the branch and Composer actually clones the repo into the correct place in your vendor directory. For tags, it copies the right files without actually cloning the repo. (You can modify this behavior with –prefer-source and –prefer-dist, see install options.)

Composerにタグの代わりにブランチをチェックアウトさせる場合は、特別なdev- *プレフィックス(またはサフィックス。以下を参照)を使用してブランチをポイントする必要があります。 ブランチをチェックアウトしている場合、ブランチで作業することを想定しているため、Composerは実際にリポジトリをベンダーディレクトリの正しい場所に複製します。 タグの場合、実際にリポジトリを複製せずに適切なファイルをコピーします。 (この動作は–prefer-sourceおよび–prefer-distで変更できます。インストールオプションを参照してください。)

In the above example, if you wanted to check out the my-feature branch, you would specify dev-my-feature as the version constraint in your require clause. This would result in Composer cloning the my-library repository into my vendor directory and checking out the my-feature branch.

上記の例で、my-featureブランチをチェックアウトする場合は、require句のバージョン制約としてdev-my-featureを指定します。 これにより、Composerはmy-libraryリポジトリをベンダーディレクトリに複製し、my-featureブランチをチェックアウトします。

When branch names look like versions, we have to clarify for composer that we're trying to check out a branch and not a tag. In the above example, we have two version branches: v1 and v2. To get Composer to check out one of these branches, you must specify a version constraint that looks like this: v1.x-dev. The .x is an arbitrary string that Composer requires to tell it that we're talking about the v1 branch and not a v1 tag (alternatively, you can name the branch v1.x instead of v1). In the case of a branch with a version-like name (v1, in this case), you append -dev as a suffix, rather than using dev- as a prefix.

ブランチ名がバージョンのように見える場合、タグではなくブランチをチェックアウトしようとしていることを作曲家に明確にする必要があります。 上記の例では、v1とv2の2つのバージョンブランチがあります。 Composerにこれらのブランチの1つをチェックアウトさせるには、v1.x-devのようなバージョン制約を指定する必要があります。 .xは、Composerがv1タグではなくv1ブランチについて話していることを伝えるために必要な任意の文字列です(または、v1の代わりにブランチにv1.xという名前を付けることができます)。 バージョンのような名前(この場合はv1)を持つブランチの場合、dev-をプレフィックスとして使用するのではなく、サフィックスとして-devを追加します。

Minimum Stability

There's one more thing that will affect which files are checked out of a library's VCS and added to your project: Composer allows you to specify stability constraints to limit which tags are considered valid. In the above example, note that the library released a beta and two release candidates for version 1.1 before the final official release. To receive these versions when running composer install or composer update, we have to explicitly tell Composer that we are ok with release candidates and beta releases (and alpha releases, if we want those). This can be done using either a project-wide minimum-stability value in composer.json or using “stability flags” in version constraints. Read more on the schema page.

ライブラリのVCSからチェックアウトされ、プロジェクトに追加されるファイルに影響するもう1つのことがあります。Composerでは、安定性の制約を指定して、有効と見なされるタグを制限できます。 上記の例では、ライブラリが最終的な公式リリースの前にベータ版とバージョン1.1の2つのリリース候補版をリリースしたことに注意してください。 composer installまたはcomposer updateの実行時にこれらのバージョンを受け取るには、リリース候補とベータリリース(および必要に応じてアルファリリース)で問題ないことをComposerに明示的に通知する必要があります。 これは、composer.jsonでプロジェクト全体の最小安定値を使用するか、バージョン制約で「安定フラグ」を使用して実行できます。 詳細については、スキーマページをご覧ください。

バージョン制約の書き方

Composerがバージョンをどのように認識するかがわかったので、プロジェクトの依存関係にバージョン制約を指定する方法について話しましょう。

正確なバージョン制約

パッケージの正確なバージョンを指定できます。これにより、Composerはこのバージョンのみをインストールするようになります。 他の依存関係が異なるバージョンを必要とする場合、ソルバーは最終的に失敗し、インストールまたは更新手順を中止します。

例: 1.0.2

バージョン範囲の指定

比較演算子を使用すると、有効なバージョンの範囲を指定できます。有効な演算子は >>=<!=です。

複数の範囲を定義できます。スペースまたはカンマ( , )で区切られた範囲は、論理ANDとして扱われます。二重パイプ( || )は論理ORとして扱われます。ANDはORよりも優先順位が高くなります。

Note:
予期せずに下位互換性を損なうバージョンをインストールする可能性があるため、無制限の範囲を使用する場合は注意してください。この場合。安全のために、キャレット演算子( ^ )の使用を検討してください。

例:

  1. >=1.0
  2. >=1.0 <2.0
  3. >=1.0 <1.1 || >=1.2

ハイフンによるバージョン範囲の指定 (-)

包括的なバージョンのセットです。右側のバージョンの一部には、ワイルドカードが含まれています。たとえば、1.0-2.02.02.0.* になるため、>=1.0.0 <2.1 と同等です。 一方、1.0.0-2.1.0>=1.0.0 ⇐2.1.0 と同等です。

例: 1.0 - 2.0

ワイルドカードによるバージョン範囲の指定 (.*)

*ワイルドカードを使用してパターンを指定できます。 1.0.* は、>=1.0 <1.1 と同等です。

例: 1.0.*

チルダによるバージョン範囲の指定 (~)

~演算子は、例で最もよく説明されています。~1.2>=1.2 <2.0.0 と同等で、~1.2.3>=1.2.3 <1.3.0と同等です。このように、セマンティックバージョニングを尊重するプロジェクトに最も役立ちます。

セマンティックバージョニング

semantic versioning(セマンティックバージョニング) はバージョン管理の命名規則を使って互換性の定義を標準化しようとする試みです。バージョン番号を3つのセクションで区切り(Major.Minor.Patch)、以下の意味付けをしています。(即ち、メジャーバージョンアップでは後方互換性が保証されません)

Major: 後方互換性を保証しないバージョンアップ
Minor: 後方互換性を保証した機能追加などのバージョンアップ
Patch: 後方互換性を保証したバグの修正によるバージョンアップ

一般的な使用法は、依存する最小のマイナーバージョンを ~1.2 のようにマークすることです(これは、2.0までは含まれますが、2.0は含まれません)。理論的には2.0まで後方互換性の中断はないはずなので、それはうまく機能します。別の見方をすれば、~の使用は最小バージョンを指定しますが、指定された最後の桁が上がることになります。

例: ~1.2

Note:
2.0-beta.1 は厳密に 2.0 より前ですが、~1.2 のようなバージョン制約ではインストールされません。上記のように、 ~1.2.2 のみが変更できることを意味しますが、1. の部分は固定されています。
Note:
~演算子には、メジャーリリース番号の動作に例外があります。これは、例えば、~1~1.0 と同じであり、下位互換性を維持しようとしてメジャー番号を増やすことができないことを意味します。

キャレットによるバージョン範囲の指定 (^)

^演算子は、セマンティックバージョニングに近いものであり非常によく似た動作をしますが、常に非破壊的な更新を許可します。例えば、^1.2.3 は、>=1.2.3 <2.0.0 と同等です。これは、2.0 が下位互換性を破るまでリリースがないためです。1.0 より前のバージョンでは、安全性を考慮して機能し、^0.3>=0.3.0 <0.4.0 として扱います。

この演算子(^)、ライブラリコードを記述するときに相互運用性を最大限に高めるための推奨演算子です。

例: ^1.2.3

Stability Constraints

安定性を明示的に定義しない制約を使用している場合、Composerは内部的に -dev または -stable をデフォルトで使用します。これは使用する演算子によって異なります。そして、これは透過的に発生します。

安定版リリースのみを明示的に検討したい場合は、接尾辞 -stable を追加して下さい。

例:

制約 内部的デフォルト
1.2.3 =1.2.3.0-stable
>1.2 >1.2.0.0-stable
>=1.2 >=1.2.0.0-dev
>=1.2-stable>=1.2.0.0-stable
<1.3 <1.3.0.0-dev
<=1.3 <=1.3.0.0-stable
1 - 2 >=1.0.0.0-dev <3.0.0.0-dev
~1.3 >=1.3.0.0-dev <2.0.0.0-dev
1.4.* >=1.4.0.0-dev <1.5.0.0-dev

ただし、制約レベルで強制せずにさまざまな安定性を許可するには、@<stability>@dev など)のような安定性フラグを使用して、特定のパッケージがデフォルトの最小安定性の設定とは異なる安定性でインストールできることをComposerに知らせることができます。使用可能なすべての安定性フラグは、スキーマページの最小安定性セクションにリストされています。


バージョン制約の要約

正確なバージョンを指定

"require": {
 
    "vendor/package": "1.3.2", // exactly 1.3.2
}

上下限を指定

"require": {
 
    // >, <, >=, <= | specify upper / lower bounds
    "vendor/package": ">=1.3.2", // anything above or equal to 1.3.2
    "vendor/package": "<1.3.2", // anything below 1.3.2
}

ワイルドカード

"require": {
 
    // * | wildcard
    "vendor/package": "1.3.*", // >=1.3.0 <1.4.0
}

指定された最後の数字が上がることを許可

"require": {
 
    // ~ | allows last digit specified to go up
    "vendor/package": "~1.3.2", // >=1.3.2 <1.4.0
    "vendor/package": "~1.3", // >=1.3.0 <2.0.0
}

破壊的更新を許さない(メジャーバージョンの固定)

"require": {
 
    // ^ | doesn't allow breaking changes (major version fixed - following semver)
    "vendor/package": "^1.3.2", // >=1.3.2 <2.0.0
    "vendor/package": "^0.3.2", // >=0.3.2 <0.4.0 // except if major version is 0
}


バージョン制約のテスト

semver.mwl.beを使用してバージョンの制約をテストできます。パッケージ名を入力すると、Composerがcomposer.json ファイルに追加するデフォルトのバージョン制約が自動入力されます。バージョン制約を調整すると、ツールは一致するすべてのリリースを強調表示します。

コメント

コメントを入力. Wiki文法が有効です:
 
composer/1.9/version-constraints.1584360387.txt.gz · 最終更新: 2020/03/16 21:06 by y2sunlight