2013-10-12 00:57:14 +00:00
|
|
|
# Why are unbound version constraints a bad idea?
|
|
|
|
|
|
2014-04-09 12:50:55 +00:00
|
|
|
A version constraint without an upper bound such as `*`, `>=3.4` or
|
|
|
|
|
`dev-master` will allow updates to any future version of the dependency.
|
|
|
|
|
This includes major versions breaking backward compatibility.
|
2013-10-12 00:57:14 +00:00
|
|
|
|
|
|
|
|
Once a release of your package is tagged, you cannot tweak its dependencies
|
2020-06-30 15:39:56 +00:00
|
|
|
anymore in case a dependency breaks BC - you have to do a new release, but the
|
2014-04-09 12:46:32 +00:00
|
|
|
previous one stays broken.
|
2013-10-12 00:57:14 +00:00
|
|
|
|
2014-04-09 12:46:32 +00:00
|
|
|
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.
|
2013-10-12 00:57:14 +00:00
|
|
|
|
2022-05-31 11:24:38 +00:00
|
|
|
For example instead of using `>=3.4` you should use `^3.4` which allows all
|
2016-06-01 13:24:13 +00:00
|
|
|
versions up to `3.999` but does not include `4.0` and above. The `^` operator
|
2017-12-29 10:33:19 +00:00
|
|
|
works very well with libraries following [semantic versioning](https://semver.org).
|
2013-10-12 00:57:14 +00:00
|
|
|
|
2020-10-26 10:11:56 +00:00
|
|
|
**Note:** As a package maintainer, you can help your users
|
2014-04-09 12:46:32 +00:00
|
|
|
by providing an [alias version](../articles/aliases.md) for your development
|
2013-10-12 00:57:14 +00:00
|
|
|
branch to allow it to match bound constraints.
|
