// Monolog はライブラリで、ベンダー名とパッケージ名が同じです。
monolog/monolog
// これはdrupalモジュールの名前のようです（monolog によって保守/提供されてます。
// drupalチームがそれを行っているとしたら、ベンダーはdrupalになります）。
monolog/monolog-drupal-module
// Acme は会社または人です。ここではパッケージに一般的な名前（Email）で名前を付けることができます。
// 独自のベンダー名前空間にある限り、他の誰とも競合しません。
acme/email
packagist のベンダー名は、ひとたび、その名前でパッケージが公開されると保護されます。つまり、packagist にすでに存在するベンダー名のパッケージを許可なしに公開することはできません。既存のベンダー名のパッケージを公開できるようにするには、そのベンダー内の少なくとも一つのパッケージの保守担当者である必要があります。
\\
===== パッケージのバージョン管理 =====
パッケージの新しいバージョンは、バージョン管理システムのリポジトリに作成したタグから自動的にフェッチされます。
バージョニングを管理する最も簡単な方法は、composer.json ファイルからバージョンフィールド( ''version'' )を省略することです。 その後は、バージョン番号はタグとブランチ名から解析されます。
タグ/バージョン名は ''X.Y.Z'' または ''vX.Y.Z'' と一致する必要があり、RC, beta, alpha または patch バージョンのオプションのサフィックスが付いています。次に、有効なタグ名の例をいくつか示します:
1.0.0
v1.0.0
1.10.5-RC1
v4.4.4beta2
v2.0.0-alpha
v2.0.4-p1
ブランチは自動的に "dev" バージョンとして表示され、ライブラリの最新かつ最高のものを試してみたい人なら誰でも簡単にインストールできますが、リリースにタグを付けてはいけないという意味ではありません。[[https://semver.org/lang/ja/|セマンティックバージョニング]]の使用を強くお勧めします。
> 例えば、''dev-master'' は masterブランチの最新バージョンを表します。
\\
===== composer.jsonの作成 =====
composer.json ファイルは、パッケージの git/svn/などの リポジトリの先頭に配置する必要があり、packagist と composer の両方にパッケージについて説明する手段となります。
典型的な composer.json ファイルは次のようになります。
{
"name": "monolog/monolog",
"type": "library",
"description": "Logging for PHP 5.3",
"keywords": ["log","logging"],
"homepage": "https://github.com/Seldaek/monolog",
"license": "MIT",
"authors": [
{
"name": "Jordi Boggiano",
"email": "j.boggiano@seld.be",
"homepage": "http://seld.be",
"role": "Developer"
}
],
"require": {
"php": ">=5.3.0"
},
"autoload": {
"psr-0": {
"Monolog": "src"
}
}
}
この情報のほとんどは明白で、キーワード( ''keywords'' )はタグであり、パッケージが持つ依存関係のリスト( ''require'' )が必要です。もちろん、これはphpバージョンだけでなく、パッケージでもかまいません。''ext-foo'' を使用して、php拡張モジュールを要求できます（例：''ext-cur''l）。ほとんどの拡張モジュールはバージョン情報を公開しない点に注意して下さい。従って、確実に公開していない限り、''"ext-curl":"*"'' を使用して、どのバージョンでも許可する方が安全です。最後に、タイプフィールド( ''type'' )ですが、上記の場合は、これがライブラリであることを示しています。フレームワークなどに対するプラグインを作成し、それらが composer を統合している場合、独自のインストーラーを使用してパッケージをインストールするために使用できるプラグイン用のカスタムパッケージタイプがある場合があります。カスタムタイプがない場合は、それを省略するか、"ライブラリ" を使用できます。
このファイルをリポジトリのルートでコミットしたら、パブリックリポジトリのURLを入力してパッケージを Packagist に[[https://packagist.org/packages/submit|送信]] できます。
\\
===== 更新スケジュール =====
New packages will be crawled immediately after submission if you have JS enabled.
JSを有効にしている場合、新しいパッケージは、送信後、即座にクロールされます。
自動更新（GitHub / BitBucketフック）のない既存のパッケージは、更新のために週に1回クロールされます。フックを有効にすると、プッシュするたびに、パッケージがクロールされ、また、クロールが失敗した場合は少なくとも月に1回はクロールされます。保守担当者としてログインしている場合は、パッケージ画面で手動更新をトリガーすることもできます。
すべてのパッケージに GitHubまたはBitBucketのサービスフックを設定することを強くお勧めします。これにより、負荷が軽減され、パッケージがほぼ瞬時に更新されます。以下のハウツーを確認してください。
* https://packagist.org/about 内の "How to update packages?" の項を参照して下さい。