Doc updat, minor GitVersion config update

Author: ajgorhoe

GitVersion.yml

@@ -1,27 +1,28 @@
+# This is the original version of GitVersion.yml. It does not invrement main
+# version on every commit, increments minor version on dev branch after
+# branching off main and adds `beta` suffix plus numbe r to versions on the
+# develop branch, and versions other branches similarly.
+# 
+# * Commits on main produce versions like 1.2.3.
+# * Commits on develop produce pre-releases like 1.3.0-beta.4.
+# * You can tune increment rules per branch, or add feature/* branches to get 1.3.0-feature.mybranch.1.
+
 
 # Configuration file for the GitVersion tool.
 
-# mode: ContinuousDeployment # commented - we leave it to built-in config
+mode: ContinuousDeployment
 workflow: GitHubFlow/v1
-strategies:
-# This enables incrementing the patch number on main branch with each commit:
-# # - ConfiguredNextVersion
-- Mainline
 branches:
-  # Configuration for main branch:
   main:
-    # Match either "main" or "master" at main branch
     regex: ^master$|^main$
     label: ''
-    # Patch number increases with new commits on the main branch
     increment: Patch
     is-release-branch: true
     is-main-branch: true
   develop:
     regex: ^develop$
-    # Add the "alpha" + incremented number suffix on develop branch:
-    label: 'alpha'
-    increment: Patch
+    label: beta
+    increment: Minor
 ignore:
   sha: []
 commit-message-incrementing: Enabled

GitVersion_CP1.yml

@@ -6,10 +6,10 @@
 
 # mode: ContinuousDeployment # commented - we leave it to built-in config
 workflow: GitHubFlow/v1
-strategies:
+# strategies:
 # This enables incrementing the patch number on main branch with each commit:
 # # - ConfiguredNextVersion
-- Mainline
+# - Mainline
 branches:
   # Configuration for main branch:
   main:

README_Development.md

@@ -171,7 +171,11 @@ You can **override behavior with certain strings in commit messages** ([see conf
 > `GitVersion` **does not work when projects / solutions are built in Visual Studio**. This is because `GitVersion` developers only support later .NET LTS and the tool needs .NET Core runtime (see [this Github Discussion](https://github.com/GitTools/GitVersion/discussions/4130)). `Visual Studio` uses stand-alone `MSBuild` that is built *for .NET Framework*, and this cannot be changed (Microsoft only releases MsBuild that is built for .NET Framework).
 > When **building or packaging with the `dotnet` tool**, **`GitVersion` works** because the `dotnet` tool contains an embedded MSBuild that is built for .NET (Core) (see [this Stack Overflow answer](https://stackoverflow.com/questions/79584977/how-can-i-force-visual-studio-to-use-msbuild-for-net-9)).
 
-In order to use GitVersion efficiently, you should tag at least the versions of main branch that are released ot published somewhere. If you know the version you want to asign, can do this on a local repostory using something like this:
+### Manually Handling Tags
+
+In order to use GitVersion efficiently, you should **tag at least the versions of main branch that are released ot published somewhere**.
+
+If you know the version tag you want to asign, you can do this on a local repostory using something like this:
 
 ~~~powershell
 # Tag the current commit on main as 1.4.0:
@@ -181,7 +185,7 @@ git tag -a v1.4.0 -m "Release 1.4.0"
 git push origin v1.4.0
 ~~~
 
-Manual tagging is error prone, and it is easy to create a wrong tag. One mitigation is to run a script where after updating the main branch, the current version is calculated by GitVersion (which correctly increments major, minor and patch numbers when commits are added and branched merged), then use this version in tagging. Below is a **PowerShell script* that tags the `main` branch with correct version number*:
+Manual **tagging a branch** is error prone, and it is easy to create a wrong tag. One mitigation is to run a script where the **current version** is **calculated by GitVersion** (which correctly increments major, minor and patch numbers when commits are added and branched merged), then use this version in tagging. Below is a **PowerShell script** that **tags the `main` branch with correct version number**:
 
 ~~~powershell
 # Update the main branch:
@@ -194,8 +198,6 @@ git tag -a "v${CurrentVersion}" -m "Released version ${CurrentVersion}"
 git push origin "v${CurrentVersion}"
 ~~~
 
-**Manually Handling Tags**:
-
 It may happen that come commits were wrongly tagged by version tags. In such cases, manual interventions with checking, deleting or re-aplying correct tags may be necessary. Here are some basic tips.
 
 Showing tags:
@@ -254,7 +256,7 @@ See detailed workflow on the Wiki .
 
 This section contains unarranged quick notes on what needs to be done.
 
-### Versioning
+**Versioning**:
 
 * Documentation
   * Wiki:
@@ -263,11 +265,11 @@ This section contains unarranged quick notes on what needs to be done.
 * scripts/TagVersion.ps1:
   * Restore branch after operation: move `$currentBranch = ...` before try, restore in finally block
   * Check Bump (ensure all variants work)
-   * add Bump...Num *NumBumps* - specifies how much to bump
-   * Copy the right version of script and GitVersion.yml to:
-     * IGLibScripts
-     * All IGLib Core repos
-     * Selected IGLib legacy repos
+  * Add Bump...Num *NumBumps* - specifies how much to bump
+  * Copy the right version of script and GitVersion.yml to:
+    * IGLibScripts
+    * All IGLib Core repos
+    * Selected IGLib legacy repos
 
 ### Helper Scripts