30 lines
1.3 KiB
Markdown
30 lines
1.3 KiB
Markdown
|
# 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).
|
||
|
|
|
||
|
|
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).
|
||
|
|
|
||
|
|
These leaves you with 3 alternatives to avoid having broken releases:
|
||
|
|
|
||
|
|
- 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)
|
||
|
|
|
||
|
|
- 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
|
||
|
|
branch to allow it to match bound constraints.
|