public-mirrors
/
composer
mirror of https://github.com/composer/composer
1
0
Fork 0
Code

Adjustments to unbound constraint docs

pull/2892/head
Jordi Boggiano 2014-04-09 14:46:32 +02:00
parent 99cfb42b8f
commit a099591735
1 changed files with 13 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
doc/faqs/why-are-unbound-version-constraints-a-bad-idea.md
View File

@ -1,29 +1,21 @@
# Why are unbound version constraints a bad idea? # Why are unbound version constraints a bad idea?
A version constraint without an upper bound will allow any future version of A version constraint without an upper bound such as `*` or `>=3.4` will allow
the dependency, even newer major version breaking backward compatibility updates to any future version of the dependency. This includes major versions
(which is the only reason to bump the major version when following semver). breaking backward compatibility.
Once a release of your package is tagged, you cannot tweak its dependencies Once a release of your package is tagged, you cannot tweak its dependencies
anymore in case a dependency breaks BC (you have to do a new release but the anymore in case a dependency breaks BC - you have to do a new release but the
previous one stays broken). previous one stays broken.
These leaves you with 3 alternatives to avoid having broken releases: The only good alternative is to define an upper bound on your constraints,
which you can increase in a new release after testing that your package is
compatible with the new major version of your dependency.
- defining an upper bound on your constraint (which you will increase in a For example instead of using `>=3.4` you should use `~3.4` which allows all
new release after testing that your package is compatible with the new versions up to `3.999` but does not include `4.0` and above. The `~` operator
version) works very well with libraries follow [semantic versioning](http://semver.org).
- knowing all future changes of your dependency to guarantee the compatibility **Note:** As a package maintainer, you can make the life of your users easier
of the current code. Forget this alternative unless you are Chuck Norris :) by providing an [alias version](../articles/aliases.md) for your development
- never release your package, but this means that all users will have to
whitelist the dev versions to install it (and complain about it)
The recommended way is of course to define an upper bound on your constraint,
so Composer will show you a warning for unbound constraints when validating
your `composer.json` file.
As a package maintainer, you can make the life of your users easier by
providing an [alias version](../articles/aliases.md) for your development
branch to allow it to match bound constraints. branch to allow it to match bound constraints.