Ground Sunlight

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

ユーザ用ツール

サイト用ツール

トレース:
composer:1.9:version-constraints

差分

このページの2つのバージョン間の差分を表示します。

この比較画面にリンクする

両方とも前のリビジョン 前のリビジョン
次のリビジョン 		前のリビジョン
composer:1.9:version-constraints [2020/03/16 21:05]
y2sunlight [Tags] 		composer:1.9:version-constraints [2020/07/08 09:51] (現在)
tanaka [キャレットによるバージョン範囲の指定 (^)]
行 11: 行 11:
   * [[composer:1.9:install|Composerのインストール]]   * [[composer:1.9:install|Composerのインストール]]
   * [[composer:1.9:phpswitch|ComposerをPHPバージョンで使い分ける]]   * [[composer:1.9:phpswitch|ComposerをPHPバージョンで使い分ける]]
 +  * [[composer:1.10:local-install|Composerのローカルインストール]]
   * [[composer:1.9:basic-usage|Composer 基本的な使い方]]   * [[composer:1.9:basic-usage|Composer 基本的な使い方]]
   * [[composer:1.9:command-list|Composer コマンド一覧]]   * [[composer:1.9:command-list|Composer コマンド一覧]]
行 25: 行 26:
 ComposerはgitなどのVCS(バージョン管理システム)の利用に重点を置いているため、「バージョン」という用語は少し曖昧な場合があります。バージョン管理システムの意味では、「バージョン」は特定のデータを含む特定のファイルセットのことです。gitの用語では、これは ''ref'' または特定のコミットであり、ブランチHEADまたはタグで表されます。あなたがVCSでそのバージョン（タグv1.1やコミットe35fa0dなど）をチェックアウトする時、単一で既知のファイルセットが要求され、常に同じファイルが返ってきます。 ComposerはgitなどのVCS(バージョン管理システム)の利用に重点を置いているため、「バージョン」という用語は少し曖昧な場合があります。バージョン管理システムの意味では、「バージョン」は特定のデータを含む特定のファイルセットのことです。gitの用語では、これは ''ref'' または特定のコミットであり、ブランチHEADまたはタグで表されます。あなたがVCSでそのバージョン（タグv1.1やコミットe35fa0dなど）をチェックアウトする時、単一で既知のファイルセットが要求され、常に同じファイルが返ってきます。
  
-Composerでは、しばしば気軽にバージョンと呼ばれるもの、つまり、''require'' でパッケージ名に続く文字列（例：''~1.1'' または ''1.2.*''）は、実際に、より具体的に言えば、それはバージョン制約のことです。Composerは、バージョン制約を使用して、VCSのどの ''ref'' をチェックアウトするかを判断します（また、''composer.json'' のバージョン仕様で静的にメンテナンスされたライブラリの場合は、特定のライブラリが受け入れられることを確認します）。+Composerでは、しばしば気軽にバージョンと呼ばれるもの、つまり、''require''キー でパッケージ名に続く文字列（例：''~1.1'' または ''1.2.*''）は、実際に、より具体的に言えば、それはバージョン制約のことです。Composerは、バージョン制約を使用して、VCSのどの ''ref'' をチェックアウトするかを判断します（また、''composer.json'' のバージョン仕様で静的にメンテナンスされたライブラリの場合は、特定のライブラリが受け入れられることを確認します）。
  
 \\ \\
  
-===== VCS Tags and Branches =====+===== VCSのタグとブランチ =====
  
 以下の説明では、次のサンプルライブラリのリポジトリを想定します。 以下の説明では、次のサンプルライブラリのリポジトリを想定します。
行 56: 行 57:
 </code> </code>
  
-==== Tags ==== +==== タグ ====
- (Note that Composer automatically removes the 'v' prefix in the actual tagname to get a valid final version number.)+
  
 通常、Composerはタグを処理します。バージョン制約を記述するとき、特定のタグ（例：''1.1''）を参照する場合と、有効なタグ範囲（例：''>= 1.1 <2.0'' または ''~4.0''）を参照する場合があります。これらの制約を解決するために、ComposerはまずVCSに利用可能な全てのタグを一覧表示するように要求し、次にこれらのタグに基づいて利用可能なバージョンの内部リストを作成します。上記の例では、composerの内部リストには、バージョン''1.0''、''1.0.1''、''1.0.2''、''1.1-BETA''、''1.1''のRC1版とRC2版、''1.1''の最終リリース版などが含まれています。（Composer有効な最終バージョン番号を取得するために、実際のタグ名の ''v''プレフィックスを自動的に削除します。 通常、Composerはタグを処理します。バージョン制約を記述するとき、特定のタグ（例：''1.1''）を参照する場合と、有効なタグ範囲（例：''>= 1.1 <2.0'' または ''~4.0''）を参照する場合があります。これらの制約を解決するために、ComposerはまずVCSに利用可能な全てのタグを一覧表示するように要求し、次にこれらのタグに基づいて利用可能なバージョンの内部リストを作成します。上記の例では、composerの内部リストには、バージョン''1.0''、''1.0.1''、''1.0.2''、''1.1-BETA''、''1.1''のRC1版とRC2版、''1.1''の最終リリース版などが含まれています。（Composer有効な最終バージョン番号を取得するために、実際のタグ名の ''v''プレフィックスを自動的に削除します。
行 64: 行 64:
  
  
-==== 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は実際にリポジトリを''vender'' ディレクトリの正しい場所に複製します。タグの場合は、実際にリポジトリを複製せずに適切なファイルをコピーします。（この動作は　''--prefer-source'' および ''--prefer-dist'' で変更できます。''install'' コマンドの[[https://getcomposer.org/doc/03-cli.md#install-i|オプション]]を参照してください。）
  
-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'' リポジトリを ''vender'' ディレクトリに複製し、''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.+ブランチ名がバージョンのように見える場合、タグではなくブランチをチェックアウトしようとしていることをComposerに明確にする必要があります。上記の例では、''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つのリリース候補版(RC1とRC2)をリリースしたことに注意してください。Composerの ''install'' または ''update'' の実行時にこれらのバージョンを受け取るには、リリース候補とβリリース（および必要に応じてαリリース）で問題ないことをComposerに明示的に通知する必要があります。これは、''composer.json'' でプロジェクト全体の「最小安定値」を使用するか、バージョン制約で「安定フラグ」を使用して実行できます。 詳細については、[[https://getcomposer.org/doc/04-schema.md#minimum-stability|スキーマページ]]をご覧ください。 
 + 
 +\\
  
 ===== バージョン制約の書き方 ===== ===== バージョン制約の書き方 =====
行 135: 行 137:
  ^演算子は、セマンティックバージョニングに近いものであり非常によく似た動作をしますが、常に非破壊的な更新を許可します。例えば、''^1.2.3'' は、''>=1.2.3 <2.0.0'' と同等です。これは、''2.0'' が下位互換性を破るまでリリースがないためです。''1.0'' より前のバージョンでは、安全性を考慮して機能し、''^0.3'' を ''>=0.3.0 <0.4.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 例: ^1.2.3
  
-===== Stability Constraints =====+\\ 
 + 
 +===== 安定性の制約 =====
 安定性を明示的に定義しない制約を使用している場合、Composerは内部的に ''-dev'' または ''-stable'' をデフォルトで使用します。これは使用する演算子によって異なります。そして、これは透過的に発生します。 安定性を明示的に定義しない制約を使用している場合、Composerは内部的に ''-dev'' または ''-stable'' をデフォルトで使用します。これは使用する演算子によって異なります。そして、これは透過的に発生します。
  
行 164: 行 168:
  
 === 正確なバージョンを指定 === === 正確なバージョンを指定 ===
-<code json>+<code javascript>
 "require": { "require": {
  
行 172: 行 176:
  
 === 上下限を指定 === === 上下限を指定 ===
-<code json>+<code javascript>
 "require": { "require": {
  
行 182: 行 186:
  
 === ワイルドカード === === ワイルドカード ===
-<code json>+<code javascript>
 "require": { "require": {
  
行 191: 行 195:
  
 === 指定された最後の数字が上がることを許可 === === 指定された最後の数字が上がることを許可 ===
-<code json>+<code javascript>
 "require": { "require": {
  
行 201: 行 205:
  
 === 破壊的更新を許さない(メジャーバージョンの固定) === === 破壊的更新を許さない(メジャーバージョンの固定) ===
-<code json>+<code javascript>
 "require": { "require": {
  
行 216: 行 220:
 [[https://semver.mwl.be/|semver.mwl.be]]を使用してバージョンの制約をテストできます。パッケージ名を入力すると、Composerが''composer.json'' ファイルに追加するデフォルトのバージョン制約が自動入力されます。バージョン制約を調整すると、ツールは一致するすべてのリリースを強調表示します。 [[https://semver.mwl.be/|semver.mwl.be]]を使用してバージョンの制約をテストできます。パッケージ名を入力すると、Composerが''composer.json'' ファイルに追加するデフォルトのバージョン制約が自動入力されます。バージョン制約を調整すると、ツールは一致するすべてのリリースを強調表示します。
  
 +\\
composer/1.9/version-constraints.1584360308.txt.gz · 最終更新: 2020/03/16 21:05 by y2sunlight

ページ用ツール

特に明示されていない限り、本Wikiの内容は次のライセンスに従います： CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki