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?
A version constraint without an upper bound will allow any future version of
the dependency, even newer major version breaking backward compatibility
(which is the only reason to bump the major version when following semver).
A version constraint without an upper bound such as `*` or `>=3.4` will allow
updates to any future version of the dependency. This includes major versions
breaking backward compatibility.
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
previous one stays broken).
anymore in case a dependency breaks BC - you have to do a new release but the
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
new release after testing that your package is compatible with the new
version)
For example instead of using `>=3.4` you should use `~3.4` which allows all
versions up to `3.999` but does not include `4.0` and above. The `~` operator
works very well with libraries follow [semantic versioning](http://semver.org).
- knowing all future changes of your dependency to guarantee the compatibility
of the current code. Forget this alternative unless you are Chuck Norris :)
- 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
**Note:** 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.