diff --git a/doc/faqs/why-are-unbound-version-constraints-a-bad-idea.md b/doc/faqs/why-are-unbound-version-constraints-a-bad-idea.md
new file mode 100644
index 000000000..a85bf35f6
--- /dev/null
+++ b/doc/faqs/why-are-unbound-version-constraints-a-bad-idea.md
@@ -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.