|
@@ -4,7 +4,6 @@
|
|
|
<div class="box clearfix">
|
|
|
<h1>What is Packagist?</h1>
|
|
|
<p>Packagist is a Composer package repository. It lets you find packages and lets Composer know where to get the code from. You can use Composer to manage your project or libraries' dependencies - read more about it on the <a href="http://getcomposer.org/">Composer website</a>.</p>
|
|
|
- <p>You can find the packagist.org source on <a href="https://github.com/composer/packagist">GitHub</a>.
|
|
|
|
|
|
<h1>How to submit packages?</h1>
|
|
|
<h2>Naming your package</h2>
|
|
@@ -55,13 +54,12 @@ acme/email
|
|
|
}
|
|
|
}
|
|
|
</pre>
|
|
|
-Most of this information is obvious, keywords are tags, require are list of dependencies that your package has. This can of course be packages, not only a php version. You can use ext-foo to require php extensions (e.g. ext-apc). Note that most extensions don't expose version information, so unless you know for sure it does, it's safer to use <code>"ext-apc": "*"</code> to allow any version of it. Finally the type field is in this case indicating that this is a library. If you do plugins for frameworks etc, and if they integrate composer, they may have a custom package type for their plugins that you can use to install the package with their own installer. In the absence of custom type, you can omit it or use "library".</p>
|
|
|
- <p>Known package types include: symfony-bundle</p>
|
|
|
+Most of this information is obvious, keywords are tags, require are list of dependencies that your package has. This can of course be packages, not only a php version. You can use ext-foo to require php extensions (e.g. ext-curl). Note that most extensions don't expose version information, so unless you know for sure it does, it's safer to use <code>"ext-curl": "*"</code> to allow any version of it. Finally the type field is in this case indicating that this is a library. If you do plugins for frameworks etc, and if they integrate composer, they may have a custom package type for their plugins that you can use to install the package with their own installer. In the absence of custom type, you can omit it or use "library".</p>
|
|
|
<p>Once you have this file committed in your repository root, you can <a href="{{ path('submit') }}">submit the package</a> to Packagist by entering the public repository URL.</p>
|
|
|
|
|
|
<h1>Managing package versions</h1>
|
|
|
<p>New versions of your package are automatically fetched from tags you create in your VCS repository.</p>
|
|
|
- <p>There are two ways to manage version numbering. The easiest is to just omit the version field from the composer.json file. If it is missing, the version name will be parsed from the tag and branch names. The other way which offers you a bit more flexibility is to define it yourself, but that means you should update the version field in the composer.json file before creating a tag, otherwise the tag will be considered broken and not imported. If you think you're likely to forget, you probably should use the first method.</p>
|
|
|
+ <p>The easiest way to manage versioning is to just omit the version field from the composer.json file. The version numbers will then be parsed from the tag and branch names.</p>
|
|
|
<p>Tag/version names should match 'X.Y.Z', or 'vX.Y.Z', with an optional suffix for RC, beta, alpha or patch versions. Here are a few examples of valid tag names:
|
|
|
<pre>
|
|
|
1.0.0
|
|
@@ -73,23 +71,22 @@ v2.0.4-p1
|
|
|
</pre>
|
|
|
Branches will automatically appear as "dev" versions that are easily installable by anyone that wants to try your library's latest and greatest, but that does not mean you should not tag releases. The use of <a href="http://semver.org/">Semantic Versioning</a> is strongly encouraged.</p>
|
|
|
|
|
|
- <p>If you specify the version manually, it will be ignored by Packagist for branches, and tags will have to contain the same version number as the tag name to be valid, so there is really no benefit to doing this.</p>
|
|
|
-
|
|
|
<h1>Update Schedule</h1>
|
|
|
|
|
|
<p>New packages will be crawled <strong>immediately</strong> after submission if you have JS enabled.</p>
|
|
|
|
|
|
- <p>Existing packages without auto-updating (GitHub hook) will be crawled <strong>once a day</strong> for updates. When the GitHub hook is enabled packages are crawled whenever you push, or at least once a week in case the crawl failed. You can also trigger a manual update on your package page if you are logged-in as a maintainer.</p>
|
|
|
+ <p>Existing packages without auto-updating (GitHub/BitBucket hook) will be crawled <strong>once a day</strong> for updates. When a hook is enabled packages are crawled whenever you push, or at least once a week in case the crawl failed. You can also trigger a manual update on your package page if you are logged-in as a maintainer.</p>
|
|
|
|
|
|
- <p>It is highly recommended to set up the <strong>GitHub service hook</strong> for all your packages. This reduces the load on our side, and ensures your package is updated almost instantly. To do so you can go to your GitHub repository, click the "Admin" button, then "Service Hooks". Pick "Packagist" in the list, and add the API key you will find on your <a href="{{ path('fos_user_profile_show') }}">profile</a>, plus your Packagist username if it is not the same as on GitHub. Check the "Active" box and submit the form.</p>
|
|
|
+ <p>It is highly recommended to set up the <strong>GitHub/BitBucket service hook</strong> for all your packages. This reduces the load on our side, and ensures your package is updated almost instantly. Check the how-to in your <a href="{{ path('fos_user_profile_show') }}">profile</a> page.</p>
|
|
|
|
|
|
- <p>If you use <strong>BitBucket</strong> or <strong>GitLab</strong> you can add a "POST" hook or Push Event and then enter 'https://packagist.org/api/update-package?username=XXX&apiToken=YYY' as the URL. To manually send update notices from other services you can build up a POST request to the previous URL and send the following JSON request body: <code>{"repository": { "url": "...the VCS url Packagist should update..."}}</code>. Do not forget to send a Content-Type header set to application/json too.</p>
|
|
|
+ <p>If you use <strong>BitBucket</strong>, <strong>GitLab</strong> or other non-supported method you can add a "POST" hook or Push Event and then enter 'https://packagist.org/api/update-package?username=XXX&apiToken=YYY' as the URL. To manually send update notices from other services you can build up a POST request to the previous URL and send the following JSON request body: <code>{"repository": { "url": "...the VCS url Packagist should update..."}}</code>. Do not forget to send a Content-Type header set to application/json too.</p>
|
|
|
|
|
|
<p>The search index is updated <strong>every five minutes</strong>. It will index (or reindex) any package that has been crawled since the last time the search indexer ran.</p>
|
|
|
|
|
|
<h1>Community</h1>
|
|
|
+ <p>If you have questions about composer or want to help out, come and join us in the <em><a href="irc://irc.freenode.net/#composer">#composer</a></em> channel on irc.freenode.net. You can find more community resources in the <a href="https://getcomposer.org/doc/06-community.md">Composer documentation</a>.</p>
|
|
|
|
|
|
- <p>If you have questions about composer or want to help out, come and join us in the <em><a href="irc://irc.freenode.net/#composer-dev">#composer-dev</a></em> channel on irc.freenode.net.</p>
|
|
|
- <p>Also join the <em><a href="http://groups.google.com/group/composer-dev">composer-dev mailing list</a></em>.</p>
|
|
|
+ <h1>Contributing</h1>
|
|
|
+ <p>To report issues or contribute code you can find the source repository on <a href="https://github.com/composer/packagist">GitHub</a>.</p>
|
|
|
</div>
|
|
|
{% endblock %}
|