allegro#325 allegro#314 Enable multi-module project lib dependency in…

…crementing.

docs/configuration/basic_usage.md

@@ -83,7 +83,7 @@ Sometimes it might be desirable to release each module (or just some
 modules) of multi-module project separately. If so, please make sure
 that:
 
--   keep in mind, that `scmVersion` must be initialized before
+-   you keep in mind that `scmVersion` must be initialized before
     `scmVersion.version` is accessed
 -   apply plugin on each module that should be released on its own
 
@@ -106,6 +106,16 @@ below:
 For example, within `module`, tags that do not start `module-` will be
 ignored. 
 
+Thus we can configure each subproject within such a multimodule project like this:
+
+```
+scmVersion {
+    tag {
+        prefix = "${project.name}"
+    }
+}
+```
+
 **IMPORTANT:**  
 
 Note that if the version separator appears in the prefix then tag parsing
@@ -150,3 +160,5 @@ versions of any submodules.  If this is desired then consider wiring the `create
 # ./gradlew cV
 0.1.0
 ```
+
+For a multimodule project which has project lib dependencies (e.g. `moduleB` `dependsOn` `project(':moduleA')`), a change within `moduleA`'s code will result in the version of `moduleA` being incremented normally.  However, `moduleB`'s code may not have changed and thus it will not have its version incremented, which is usually not the desired behaviour.  This issue is rectified by the 2 tasks, `createReleaseDependents` and `releaseDependents`.  These tasks are analogous to `createRelease` and `release`, respectively, and traverse the inter-project dependency tree and cause the creation of releases for all projects that have a declared dependency on a project(s) whose code has changed.  Thus, for the example just cited, a new release would be created for `moduleB`.  This is modelled on how the Java plugin's `buildNeeded` and `buildDependents` tasks work (described [here](https://docs.gradle.org/current/userguide/multi_project_builds.html#sec:multiproject_build_and_test)).

docs/configuration/tasks.md

@@ -1,14 +1,18 @@
 # Tasks
 
-`axion-gradle-plugin` adds 6 new Gradle tasks:
+`axion-gradle-plugin` adds 8* new Gradle tasks:
 
 -   *verifyRelease*
 -   *release*
 -   *createRelease*
+-   *releaseDependents*
+-   *createReleaseDependents*
 -   *pushRelease*
 -   *currentVersion*
 -   *markNextVersion*
 
+*The plugin also creates a helper task called `configureReleaseDependentsTasks` that is called internally, but this is not designed to be called by users.
+
 ## verifyRelease
 
 Runs all checks before release. **release** task depends on it. See
@@ -29,6 +33,14 @@ of these tasks running exactly one after another.
 
 Run pre-release actions ([Pre/post release hooks](hooks.md)) and create release tag.
 
+## releaseDependents
+
+Works as per `release`, except that releases are created on any submodules that depend on the project in which this task is called, including transitive dependencies (i.e. changes to `moduleA` will generate releases for `moduleB` and `moduleC`, assuming `moduleC` depends on `moduleB` depends on `moduleA`).  This is described in further detail in [Basic Usage](../basic_usage.md).
+
+## createReleaseDependents
+
+Works as per `createRelease`, except that releases are created on any submodules that depend on the project in which this task is called, including transitive dependencies (i.e. changes to `moduleA` will generate releases for `moduleB` and `moduleC`, assuming `moduleC` depends on `moduleB` depends on `moduleA`).  This is described in further detail in [Basic Usage](../basic_usage.md).
+
 ## pushRelease
 
 Push tag to remote.