Update output of the hello library (#1614)

creating_packages/getting_started.rst

@@ -214,9 +214,9 @@ You can create and test the package with our default settings simply by running:
 
     $ conan create . demo/testing
     ...
-    Hello world!
+    Hello world Release!
 
-If "Hello world!" is displayed, it worked.
+If "Hello world Release!" is displayed, it worked.
 
 The :command:`conan create` command does the following:
 

creating_packages/package_repo.rst

@@ -92,7 +92,7 @@ And simply create the package for user and channel **demo/testing** as described
     $ conan create . demo/testing
     ...
     Hello/0.1@demo/testing test package: Running test()
-    Hello world!
+    Hello world Release!
 
 .. _scm_feature:
 
@@ -114,13 +114,13 @@ remote and commit of the local repository:
     from conans import ConanFile, CMake, tools
 
     class HelloConan(ConanFile):
-         scm = {
+        scm = {
             "type": "git",  # Use "type": "svn", if local repo is managed using SVN
             "subfolder": "hello",
             "url": "auto",
             "revision": "auto",
             "password": os.environ.get("SECRET", None)
-         }
+        }
         ...
 
 You can commit and push the *conanfile.py* to your origin repository, which will always preserve the ``auto``
@@ -206,4 +206,3 @@ be valid too:
    and by default, the :command:`conan upload` will block the upload of the recipe. This prevents recipes
    to be uploaded with incorrect scm values exported.
    You can use :command:`conan upload --force` to force uploading the recipe with the "auto" values un-replaced.
-

developing_packages/package_dev_flow.rst

@@ -206,8 +206,8 @@ As a summary, you could use the default folders and the flow would be as simple
 
 .. code-block:: bash
 
-    $ git clone git@github.com:memsharded/example_conan_flow.git
-    $ cd example_conan_flow
+    $ git clone https://github.com/conan-io/examples.git
+    $ cd features/package_development_flow
     $ conan source .
     $ conan install . -pr=default
     $ conan build .
@@ -218,7 +218,7 @@ As a summary, you could use the default folders and the flow would be as simple
     $ conan test test_package Hello/1.1@user/testing
     ...
     Hello/1.1@user/testing (test package): Running test()
-    Hello World!
+    Hello World Release!
 
 conan create
 ^^^^^^^^^^^^

devtools/running_packages.rst

@@ -65,15 +65,16 @@ This will generate a few files that can be called to activate and deactivate the
 
     $ activate_run.sh # $ source activate_run.sh in Unix/Linux
     $ greet
-    > Hello World!
+    > Hello World Release!
     $ deactivate_run.sh # $ source deactivate_run.sh in Unix/Linux
 
 Imports
 -------
 
-It is possible to define a custom conanfile (either .txt or .py), with an ``imports`` section, that can retrieve from local
+It is possible to define a custom conanfile (either *.txt* or *.py*), with an ``imports()`` section, that can retrieve from local
 cache the desired files. This approach requires a user conanfile.
-For more details see example below :ref:`runtime packages<repackage>`
+
+For more details see the example below :ref:`runtime packages<repackage>`.
 
 Deployable packages
 -------------------
@@ -100,7 +101,7 @@ With that method in our package recipe, it will copy the executable when install
     ...
     > Hello/0.1@user/testing deploy(): Copied 1 '.exe' files: greet.exe
     $ bin\greet.exe
-    > Hello World!
+    > Hello World Release!
 
 The deploy will create a *deploy_manifest.txt* file with the files that have been deployed.
 
@@ -121,7 +122,9 @@ with:
 Using the `deploy` generator
 ----------------------------
 
-The :ref:`deploy generator <deploy_generator>` is used to have all the dependencies of an application copied into a single place. Then all the files can be repackaged into the distribution format of choice.
+The :ref:`deploy generator <deploy_generator>` is used to have all the dependencies of an application copied into a single place. Then all
+the files can be repackaged into the distribution format of choice.
+
 For instance, if the application depends on boost, we may not know that it also requires many other 3rt-party libraries, 
 such as 
 `zlib <https://zlib.net/>`_, 
@@ -141,14 +144,16 @@ This helps to collect all the dependencies into a single place, moving them out
 Using the `json` generator
 --------------------------
 
-A more advanced approach is to use the :ref:`json generator <json_generator>`:
-This generator works in a similar fashion as the `deploy` one, although it doesn't copy the files to a directory. Instead, it generates a JSON file with all the information about the dependencies including the location of the files in the Conan cache.
+A more advanced approach is to use the :ref:`json generator <json_generator>`. This generator works in a similar fashion as the
+`deploy` one, although it doesn't copy the files to a directory. Instead, it generates a JSON file with all the information about the
+dependencies including the location of the files in the Conan cache.
 
 .. code-block:: bash
 
     $ conan install . -g json
 
-The *conanbuildinfo.json* file produced is fully machine-readable and could be used by scripts to prepare the files and recreate the appropriate format for distribution. The following code shows how to read the library and binary directories from the *conanbuildinfo.json*:
+The *conanbuildinfo.json* file produced, is fully machine-readable and could be used by scripts to prepare the files and recreate the
+appropriate format for distribution. The following code shows how to read the library and binary directories from the *conanbuildinfo.json*:
 
 .. code-block:: python
 
@@ -174,7 +179,9 @@ The *conanbuildinfo.json* file produced is fully machine-readable and could be u
                     bin_dir = os.path.relpath(bin_path, root)
                     dep_bin_dirs[bin_path] = bin_dir
 
-While with the `deploy` generator all the files were copied into a folder, the advantage with the `json` one is that you have fine-grained control over the files and those can be directly copied to the desired layout.
+While with the `deploy` generator, all the files were copied into a folder. The advantage with the `json` one is that you have fine-grained
+control over the files and those can be directly copied to the desired layout.
+
 In that sense, the script above could be easily modified to apply some sort of filtering (e.g. to copy only shared libraries, 
 and omit any static libraries or auxiliary files such as pkg-config .pc files).
 
@@ -203,15 +210,11 @@ Additionally, you could also write a simple startup script for your application
            ld_library_path=ld_library_path,
            exe=exe)
 
-.. note::
-
-    The full example might be found on `GitHub <https://github.com/conan-io/examples/tree/master/features>`_.
-
 Running from packages
 ---------------------
 
 If a dependency has an executable that we want to run in the conanfile, it can be done directly in code
-using the ``run_environment=True`` argument. It internally uses a ``RunEnvironment()`` helper. 
+using the ``run_environment=True`` argument. It internally uses a ``RunEnvironment()`` helper.
 For example, if we want to execute the :command:`greet` app while building the ``Consumer`` package:
 
 .. code-block:: python
@@ -234,7 +237,7 @@ Now run :command:`conan install` and :command:`conan build` for this consumer re
     $ conan install . && conan build .
     ...
     Project: Running build()
-    Hello World!
+    Hello World Release!
 
 Instead of using the environment, it is also possible to explicitly access the path of the dependencies:
 
@@ -317,7 +320,7 @@ Installing and running this package can be done using any of the methods present
     # It will not install Hello/0.1@...
     $ activate_run.sh # $ source activate_run.sh in Unix/Linux
     $ greet
-    > Hello World!
+    > Hello World Release!
     $ deactivate_run.sh # $ source deactivate_run.sh in Unix/Linux
 
 .. _deployment_challenges:

howtos/custom_generators.rst

@@ -128,15 +128,15 @@ Put the following files inside. Note the ``PremakeGen@0.1@myuser/testing`` packa
     [requires]
     hello/0.1@myuser/testing
     PremakeGen@0.1@myuser/testing
-    
+
     [generators]
     Premake
 
 .. code-block:: cpp
    :caption: *main.cpp*
 
     #include "hello.h"
-    
+
     int main (void) {
         hello();
     }
@@ -185,7 +185,7 @@ Now we are ready to build the project:
     $ premake4 gmake
     $ make (or mingw32-make if in windows-mingw)
     $ ./MyApplication
-    Hello World!
+    Hello World Release!
 
 Now everything works, so you might want to share your generator: