Rework flow for more features

Signed-off-by: psakiev <psakiev@sandia.gov>

Author: psakievich

tutorial_developer_workflows.rst

@@ -160,13 +160,6 @@ So how does Spack determine the value of the ``dev_path`` variant?
 By default, the source code is downloaded into a subdirectory of the environment using Spack's staging functionality.
 You can change the location of this source directory by modifying the ``path:`` attribute of the develop configuration in the environment or by passing the ``--path`` options when calling ``spack develop``.
 
-There are a few gotchas with the ``spack develop`` command
-
-* Spack needs to know the version of the dev package so it can supply the correct flags for the package's build system.
-  If a version is not supplied or detectable in the environment, then Spack falls back to the maximum version defined in the package where `infinity versions <https://spack.readthedocs.io/en/latest/packaging_guide_creation.html#version-comparison>`_ like ``develop`` and ``main`` have a higher value than the numeric versions.
-* You should ensure a spec for the package you are developing appears in the DAG of at least one of the roots of the environment with the same version that you are developing.
-  ``spack add <package>`` with the matching version you want to develop is a way to ensure the develop spec is satisfied in the ``spack.yaml`` environments file.
-  This is because develop specs are not concretization constraints but rather criteria for adding the ``dev_path=`` variant to existing spec.
 
 .. literalinclude:: outputs/dev/develop-conc.out
    :language: console
@@ -218,6 +211,25 @@ If we were co-developing ``macsio``, we could run
 .. literalinclude:: outputs/dev/develop-5.out
    :language: console
 
+Note that we intentionally gave a different version and in the examples above ``macsio`` never received the ``dev_path`` variant.
+This example  is to show a few gotchas with the ``spack develop`` command
+
+* You should ensure a spec for the package you are developing appears in the DAG of at least one of the roots of the environment with the same version that you are developing.
+  ``spack add <package>`` with the matching version you want to develop is a way to ensure the develop spec is satisfied in the ``spack.yaml`` environments file.
+  This is because develop specs are not concretization constraints but rather criteria for adding the ``dev_path=`` variant to existing spec.
+* Spack needs to know the version of the dev package so it can supply the correct flags for the package's build system.
+  If a version is not supplied or detectable in the environment, then Spack falls back to the maximum version defined in the package where `infinity versions <https://spack.readthedocs.io/en/latest/packaging_guide_creation.html#version-comparison>`_ like ``develop`` and ``main`` have a higher value than the numeric versions.
+
+If we really wanted to change to developing ``macsio@develop`` we need to change the root spec in the environment and then reconcretize.
+
+In our case the ``1.1`` version is sufficient and we will use this as an opportunity to introduce another ``spack develop`` feature: the ``--recursive`` option.
+``spack develop --recursive`` can only be used with a concrete environment.
+When called Spack traces the graph from the supplied develop spec to every root in the graph that transitivley depends on the develop package.
+This is a nice way to ensure that all specs are skipping restages, and performing incremental builds if their build-system allows for it.
+
+.. literalinclude:: outputs/dev/develop-6.out
+   :language: console
+
 Using development workflows also lets us ship our whole development process to another developer on the team.
 They can simply take our spack.yaml, create a new environment, and use this to replicate our build process.
 For example, we'll make another development environment here.