(#9548) Clarify importance of options when protecting from recipe cha…

…nges

* Clarify importance of options when protecting from recipe changes

* Apply suggestions from code review

Co-authored-by: Javier G. Sogo <jgsogo@gmail.com>

* Update docs/faqs.md

Co-authored-by: Uilian Ries <uilianries@gmail.com>

* Update docs/faqs.md

Co-authored-by: SpaceIm <30052553+SpaceIm@users.noreply.github.com>

Co-authored-by: Javier G. Sogo <jgsogo@gmail.com>
Co-authored-by: Uilian Ries <uilianries@gmail.com>
Co-authored-by: SpaceIm <30052553+SpaceIm@users.noreply.github.com>

docs/faqs.md

@@ -319,11 +319,18 @@ features that will be broken unless you also upgrade Conan client (and sometimes
 need to modify your project if the recipe changes the binaries, flags,... it provides).
 
 To isolate from this changes there are different strategies you can follow:
+
+The minimum solution involves small changes to your Conan client configuration by
+
+* **Pin the version of every reference you consume in your project** using either:
+  * [recipe revision (RREV)](https://docs.conan.io/en/latest/versioning/revisions.html): `foo/1.0@#RREV` instead of `foo/1.0` in your conanfile.
+  * [lockfiles](https://docs.conan.io/en/latest/versioning/lockfiles/introduction.html).
+
+For larger projects and teams it is recommended to add some infrastructure to ensure stability by
+
  * **Cache recipes in your own Artifactory**: your project should use only this remote and
    new recipe revisions are only pushed to your Artifactory after they have been validated
    in your project.
- * **Pin the version of every reference you consume in your project** using recipe revisions
-   and lockfiles. 
 
 Keep reading in the [consuming recipes section](consuming_recipes.md).