Update documentation in docs/input/docs/reference/modes/*

Author: HHobeck

docs/input/docs/reference/modes/continuous-delivery.md

@@ -2,75 +2,33 @@
 Order: 20
 Title: Continuous Delivery
 Description: |
-    Continuous Delivery is the default versioning mode. In this mode,
-    GitVersion calculates the next version and will use that until that is
-    released.
+    Sometimes you just want the version to keep changing and deploy continuously
+	to an testing system. In this case, __Continuous Delivery__ is a good mode to
+	operate GitVersion by.
 RedirectFrom: docs/reference/versioning-modes/continuous-delivery
 ---
 
-Continuous Delivery is the practice of having a deployment pipeline and is the
-default mode in GitVersion. Each stage of the pipeline gets the code going
-through the pipeline closer to production.
+Continuous Delivery is the process of checking into a branch, running all the
+tests and if everything goes green it is automatically pushed to a testing system.
 
-The topic itself is rather large, here we will just focus on the building and
-creation of _releasable_ artifacts. This is only a part of continuous delivery
-as a whole, with the hard part being the ability to measure the impacts of what
-you have deployed into production.
+A good case for Continuous Delivery is when using Octopus deploy, as you
+cannot publish the same version of a package into the same feed.
 
-In essence continuous delivery means:
-
-* Your code is automatically built and tested
-* If any of the automated tests fail, the team's #1 priority is to fix the
-    build
-* If the build is green, the application can be deployed at any time
-  * Ideally the business should make that decision
-  * The same artifacts which were built and tested should be deployed
-  * That means no rebuilding everything when you are deploying
-
-Continuous delivery does not work well with GitFlow. The reason is that you are
-required to _merge_ to main to do a release, triggering a rebuild and a new
-set of artifacts to go through your pipeline. Depending on how long your
-pipeline is, this could be a while.
-
-GitHubFlow is a better fit for Continuous delivery, the [mainline
-development][mainline] model means that every merged feature branch will be
-built as a _stable_ version and if the build/builds go green then you are free
-to deploy to production at any time.
-
-## Usage
-
-By default, GitVersion is set up to do Continuous Delivery on all branches but
-`develop`, which is set up with [Continuous Deployment][continuous-deployment].
-To change the mode to Continuous Delivery, change your
-[configuration][configuration] to:
-
-```yaml
-mode: ContinuousDelivery
-```
+For this mode we follow the logic in [this blog post by Xavier Decoster][blog]
+on the issues of incrementing automatically.
 
 ## How Continuous Delivery affects GitVersion
 
-The thing about continuous delivery is that there will be _multiple_ candidates
-to deploy to production and it is a human choice to deploy. This means that
-GitVersion will build **the same semantic version** until that version is
-deployed. For instance:
-
-* 1.1.0+5
-* 1.1.0+6
-* 1.1.0+7  <-- This is the artifact we release, tag the commit which created
-    this version
-* 1.1.1+0
-
-Tags are required in this mode to communicate when the release is done as it's
-an external manual process.
+Continuous delivery is good when you deploy continuously to an testing system.
 
-## Resources
+* 1.1.0-3
+* 1.1.0-2 (tag: 1.1.0-2) <-- This is the version which has been deployed on testing
+* 1.1.0-1
+* 1.1.1-0
 
-* [Continuous Delivery on Wikipedia][wikipedia]
-* [Continuous Delivery, the book][book]
+Tags are not required but optional in this mode to communicate when the release
+is done as it's an automated process.
 
-[book]: https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912
 [configuration]: /docs/reference/configuration
-[continuous-deployment]: /docs/reference/modes/continuous-deployment
-[mainline]: /docs/reference/modes/mainline
+[blog]: https://www.xavierdecoster.com/semantic-versioning-auto-incremented-nuget-package-versions
 [wikipedia]: https://en.wikipedia.org/wiki/Continuous_delivery

docs/input/docs/reference/modes/continuous-deployment.md

@@ -3,42 +3,27 @@ Order: 30
 Title: Continuous Deployment
 Description: |
     Sometimes you just want the version to keep changing and deploy continuously.
-    In this case, Continuous Deployment is a good mode to operate GitVersion by.
 RedirectFrom: docs/reference/versioning-modes/continuous-deployment
 ---
 
-Continuous Deployment is the process of checking into main, running all the
-tests and if everything goes green it is automatically pushed to production.
-
-A good case for Continuous Deployment is when using Octopus deploy, as you
-cannot publish the same version of a package into the same feed.
+Continuous Deployment is the process of checking into main and automatically
+deploying to production.
 
 For this mode we follow the logic in [this blog post by Xavier Decoster][blog]
 on the issues of incrementing automatically.
 
-As such we force a pre-release tag on all branches, this is fine for
-applications but can cause problems for libraries. As such this mode may or may
-not work for you, which leads us into a new mode in v4 of GitVersion:
-[Mainline Development][mainline].
-
-### Usage
+## How Continuous Deployment affects GitVersion
 
-By default GitVersion is set up to do Continuous Deployment versioning on the
-`develop` branch, but for all other branches, [Continuous
-Delivery][continuous-delivery] is the default mode. From version 3 of GitVersion
-this behavior is [configurable][configuration].
+The thing about continuous deployment is that there will be only one version
+to deploy on production. This means that GitVersion will build
+**the same semantic version** for every commit until it has been tagged. For instance:
 
-The default behavior for v3 and how v1 & 2 worked was that the version only
-incremented after a tag, which signified a release. In v3 you can simply switch
-the default mode in the [configuration][configuration] from `ContinuousDelivery`
-to `ContinuousDeployment` and the version will then increment each commit,
-giving you the features of GitVersion with continuous deployment:
+* 1.2.0
+* 1.1.0 (tag: 1.1.0) <-- This is the version which has been deployed on production
+* 1.1.0
+* 1.1.1
 
-```yaml
-mode: ContinuousDeployment
-```
+Tags are required in this mode to communicate when the deployement happens on production.
 
-[blog]: https://www.xavierdecoster.com/semantic-versioning-auto-incremented-nuget-package-versions
 [configuration]: /docs/reference/configuration
-[continuous-delivery]: /docs/reference/modes/continuous-delivery
-[mainline]: /docs/reference/modes/mainline
+[blog]: https://www.xavierdecoster.com/semantic-versioning-auto-incremented-nuget-package-versions

docs/input/docs/reference/modes/mainline.md

@@ -0,0 +1,38 @@
+---
+Order: 10
+Title: Manual Deployment
+Description: |
+    The __Manual Deployment__ mode can be used to remain on the same pre-released
+	version until it has been deployed dedicatedly.
+	
+RedirectFrom: docs/reference/versioning-modes/manual-deployment
+---
+
+Having not the necessity to deploy the build artifacts on every commit is an
+indecation of using the __Manual Deployment__ mode. This mode can be used to
+remain on the same pre-released version until it has been deployed dedicatedly.
+
+## How Manual Deployment affects GitVersion
+
+The thing about manual deployment is that there will be _multiple_ candidates
+to deploy on testing and it is a human choice to deploy. This means that
+GitVersion will build **the same semantic version** until that version is
+deployed. For instance:
+
+* 1.1.0-2+1
+* 1.1.0-1+2 (tag: 1.1.0-1) <-- This is the version which has been deployed on testing
+* 1.1.0-1+1
+* 1.1.1-1+0
+
+Tags are required in this mode to communicate when the release is done as it's
+an external manual process.
+
+## Resources
+
+* [Configuration][configuration]
+* [Continuous Delivery on Wikipedia][wikipedia]
+* [Continuous Delivery, the book][book]
+
+[configuration]: /docs/reference/configuration
+[book]: https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912
+[wikipedia]: https://en.wikipedia.org/wiki/Continuous_delivery