# composer keeps a 2.10 line and a 2.2 LTS line alive at once, and self-update picks between them > composer is the dependency manager for PHP projects, MIT licensed, and it ships two release lines in parallel. Its solver began as a port of openSUSE's satsolver, it expects unzip and git to exist as binaries on the host, and the README hands both installation and usage to web pages rather than to anything in the repository. **composer/composer** — Dependency Manager for PHP - Repository: https://github.com/composer/composer - Website: https://getcomposer.org/ - Stars: 29,536 · Forks: 4,843 - Language: PHP - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/composer-composer ## Two release lines shipped on the same day, and self-update chooses one for you The release trail holds two lines at once. On 2026-08-27 the project published 2.10.3 and 2.2.30 within three seconds of each other, and 2.10.2 had gone out on 2026-07-01. The rule that connects them is stated plainly: if you run the installer or the `self-update` command, the appropriate Composer version for your PHP should be automatically selected. That makes your Composer's release line a function of your PHP version rather than a version you chose, which has two consequences worth planning for. Raising PHP on a host can move that host to a different Composer line than the one your documentation names, and the version you get back from an update is not necessarily the version you asked for. When you pin a Composer version in a base image, write down the PHP version beside it, because one implies the other. ## Two PHP floors, and the LTS window is wider than the latest line's The requirements section names two support windows rather than one. The latest Composer needs PHP 7.2.5 or above. The 2.2 LTS line, taken as 2.2.x releases, supports PHP versions 5.3.2 through 8.1, and it is still receiving builds, which is what a 2.2.30 tag dated 2026-08-27 alongside 2.10.3 tells you. The two floors do not line up, and that gap is where the confusion lives. A host on PHP 8.2 or newer can only use the latest line, since the LTS ceiling is 8.1. A host below 7.2.5 is confined to 2.2.x, which means the old line is the only one still shipping for it. What the README does not give you is an end-of-support date for either line, so if you are holding a host on an old PHP, the date that matters to you is not written down anywhere in the documentation. ## Ten binaries are named, two are called essential, and the shortcut is discouraged The binary dependency list runs to ten entries: `unzip` (or `7z`/`7zz`), `gzip`, `tar`, `unrar`, `xz`, Git, Mercurial, Fossil, Perforce, and Subversion. The requirement that matters is narrower than the list, because the need varies by use case and for most users only two are essential, `unzip` (or `7z`/`7zz`) and `git`. There is also a shortcut, since if the `ext-zip` extension is available only `git` is needed, and the project attaches a warning to it: this is not recommended. No reason is given for that discouragement, which leaves you to decide it yourself. The practical consequence is about where failures show up. A slim container image without unzip fails when composer needs to unpack an archive, not at some earlier prerequisite step, and the five VCS clients only matter if you install from those particular hosts. ## The README hands installation and usage to two web pages and names no install command There is no command in this repository's README that installs composer. Installation is delegated: download and install Composer by following the official instructions, linked to getcomposer.org/download/. Usage is delegated the same way, to the documentation at getcomposer.org/doc/. Meanwhile the tree itself holds bin/, src/, tests/, res/, doc/, composer.json, composer.lock, phpstan/, and phpunit.xml.dist, so the code and a doc directory are right there while the entry point is a page on the web. For a provisioning script, a container image, or a locked-down build host, that matters: you cannot derive an install step from a checkout, so the instructions have to be sourced from outside the repository. The single command named anywhere in the page is `self-update`, which is the upgrade path, not the install path, and its version selection is the automatic one described above. ## The solver is a port of openSUSE's satsolver, and the 2.0 notes sit in the root One line in the acknowledgements explains where the hard part came from: this project's Solver started out as a PHP port of openSUSE's Libzypp satsolver. That is the dependency resolution engine, so the model behind version conflicts, constraints, and the wording of resolution errors descends from a distribution package manager rather than from a PHP-native design. The practical consequence shows up when a resolution surprises you: the semantics you need to reason about live in the upstream satsolver model, and the file that answers how the port behaves is a PHP port, not the original. The root also carries UPGRADE-2.0.md and PORTING_INFO next to CHANGELOG.md, which means the jump from the 1.x line to 2.0 is documented in the tree. If you are following a 1.x-era tutorial, that file is the first thing to read. ## Composer locks its own dependencies, so a resolver change moves the tool itself The repository root contains composer.json and composer.lock, meaning the tool is installed with itself, against a dependency set that is pinned in the tree rather than resolved on every clone. Alongside them sit phpstan/ for static analysis, phpunit.xml.dist for the test run, and .php-cs-fixer.php for formatting, so the same repository carries the linting, analysis, and test configuration used to keep the client healthy. Two things follow. A change to solver behaviour or to the minimum PHP requirement is not just a change to composer's own code, it is a change to the locked graph the project tests against, so resolver regressions surface in composer's own build before they reach yours. And when you read a bug report about dependency resolution, you are reading about code whose dependency set you can inspect directly, which is worth doing before you go looking for a workaround. ## Client security reports are routed to a packagist.org address The security section is short: send any sensitive issue to security@packagist.org, and no other address is offered. The point worth noticing is which project that address belongs to, since the client tool and the public package registry are run by the same organization, and the sponsor page funds Composer and Packagist.org together, listing AWS, Datadog, Algolia, Socket.dev, Aikido, Upsun, Bunny.net, Tideways, Sovereign Tech, and Packagist itself. So a vulnerability in the composer binary is triaged by the same body that operates the registry your code is downloaded from. If your own policy demands that a client bug reach the tool's own maintainers, this is the route the project names. The same split applies to packages: public ones live on Packagist.org, while private hosting is a separate product, Private Packagist, reached by the same client under a different configuration. ## Conclusion Use composer when the host runs a PHP version the 2.10 line supports, unzip and git are actually present, and your packages come from Packagist or Private Packagist. Do not treat it as a PHP version manager, and do not expect the repository to document how to install the tool, because that instruction lives on a website and not in the tree. Before you commit, check the PHP version on every host that runs it, confirm the two essential binaries rather than assuming a slim image has them, and read UPGRADE-2.0.md if you are arriving from Composer 1. ## FAQ ### What is composer? It is the dependency manager for PHP projects: composer helps you declare, manage, and install dependencies of PHP projects. It is MIT licensed, maintained in the composer organization, and documented at getcomposer.org. ### how to install composer The README contains no install command and points you to the official instructions at getcomposer.org/download/. The only command it names is `self-update`, which selects the Composer version appropriate for your PHP. ### how to use composer Usage is documented at getcomposer.org/doc/ rather than in the repository, which links out instead of shipping commands. In the repository itself, bin/, src/, doc/, tests/, and composer.json show the layout of the client, and the Solver is a PHP port of openSUSE's Libzypp satsolver. ### how to use composer phar The README does not mention a phar build anywhere. Installation is delegated to the official instructions page, so whether you receive a phar or an installer depends on what that page gives you for your platform. ### how to use composer 2.5 There is no 2.5 line in the release trail shown here, which moves between 2.10.2, 2.10.3, and a 2.2.30 LTS build. Two lines are supported: the latest, needing PHP 7.2.5 or above, and the 2.2 LTS, covering PHP 5.3.2 through 8.1. ### how to install composer in windows Nothing in the README is Windows specific. Installation for every platform is delegated to the official instructions page, and the only platform adjacent detail is the binary dependency list, where `unzip` (or `7z`/`7zz`) and `git` are the two called essential. ## Sources - [composer/composer on GitHub](https://github.com/composer/composer) - [License: MIT](https://github.com/composer/composer/blob/main/LICENSE) - [Project website](https://getcomposer.org/) - [README](https://github.com/composer/composer/blob/main/README.md) - [Releases](https://github.com/composer/composer/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/composer-composer