|
|
@@ -0,0 +1,29 @@
|
|
|
+# 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.
|
Jordi Boggiano