Adjustments to unbound constraint docs

doc/faqs/why-are-unbound-version-constraints-a-bad-idea.md

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