docs: promote semantic versioning less aggressively

docs/faq.md

@@ -33,21 +33,32 @@ Once Poetry has cached the releases' information on your machine, the dependency
 will be much faster.
 will be much faster.
 {{% /note %}}
 {{% /note %}}
 
 
-### Why are unbound version constraints a bad idea?
+### Are unbound version constraints a bad idea?
 
 
 A version constraint without an upper bound such as `*` or `>=3.4` will allow updates to any future version of the dependency.
 A version constraint without an upper bound such as `*` or `>=3.4` will allow updates to any future version of the dependency.
 This includes major versions breaking backward compatibility.
 This includes major versions breaking backward compatibility.
 
 
 Once a release of your package is published, you cannot tweak its dependencies anymore in case a dependency breaks BC
 Once a release of your package is published, 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.
 – you have to do a new release but the previous one stays broken.
+(Users can still work around the broken dependency by restricting it by themselves.)
 
 
-The only good alternative is to define an upper bound on your constraints,
+To avoid such issues you can define an upper bound on your constraints,
 which you can increase in a new release after testing that your package is compatible
 which you can increase in a new release after testing that your package is compatible
 with the new major version of your dependency.
 with the new major version of your dependency.
 
 
-For example instead of using `>=3.4` you should use `^3.4` which allows all versions `<4.0`.
+For example instead of using `>=3.4` you can use `^3.4` which allows all versions `<4.0`.
 The `^` operator works very well with libraries following [semantic versioning](https://semver.org).
 The `^` operator works very well with libraries following [semantic versioning](https://semver.org).
 
 
+However, when defining an upper bound, users of your package are not able to update
+a dependency beyond the upper bound even if it does not break anything
+and is fully compatible with your package.
+You have to release a new version of your package with an increased upper bound first.
+
+If your package will be used as a library in other packages, it might be better to avoid
+upper bounds and thus unnecessary dependency conflicts (unless you already know for sure
+that the next release of the dependency will break your package).
+If your package will be used as an application, it might be worth to define an upper bound.
+
 ### Is tox supported?
 ### Is tox supported?
 
 
 **Yes**. By using the [isolated builds](https://tox.readthedocs.io/en/latest/config.html#conf-isolated_build) `tox` provides,
 **Yes**. By using the [isolated builds](https://tox.readthedocs.io/en/latest/config.html#conf-isolated_build) `tox` provides,

docs/libraries.md

@@ -19,10 +19,11 @@ This chapter will tell you how to make your library installable through Poetry.
 
 
 Poetry requires [PEP 440](https://peps.python.org/pep-0440)-compliant versions for all projects.
 Poetry requires [PEP 440](https://peps.python.org/pep-0440)-compliant versions for all projects.
 
 
-While Poetry does not enforce any release convention, it does encourage the use of
+While Poetry does not enforce any release convention, it used to encourage the use of
 [semantic versioning](https://semver.org/) within the scope of
 [semantic versioning](https://semver.org/) within the scope of
-[PEP 440](https://peps.python.org/pep-0440/#semantic-versioning). This has many advantages for the end users
-and allows them to set appropriate [version constraints]({{< relref "dependency-specification#version-constraints" >}}).
+[PEP 440](https://peps.python.org/pep-0440/#semantic-versioning) and supports
+[version constraints]({{< relref "dependency-specification/#caret-requirements" >}})
+that are especially suitable for semver.
 
 
 {{% note %}}
 {{% note %}}