Improve listing of version strategies in how-it-works.md

Author: selfdocumentingcode

docs/input/docs/learn/how-it-works.md

@@ -19,8 +19,7 @@ GitVersion has three distinct steps for calculating versions in v3.
 1. If the current commit is tagged, the tag is used and build metadata
     (excluding commit count) is added. The other two steps will not execute.
 2. A set of strategies are evaluated to decide on the base version and some
-    metadata about that version.  These strategies include HighestReachableTag,
-    NextVersionInConfig, MergedBranchWithVersion, VersionInBranchName etc.
+    metadata about that version. See [Version Strategies](#version-strategies)
 3. The highest base version is selected, using that base version as the new
     version is calculated.
 
@@ -35,35 +34,36 @@ info below.
 **+** This version is out of context with the rest of the example. It is here
 simply to show what happens if the check is true.
 
-### Base Version Strategies
+### Version Strategies
 
 Currently we have the following strategies:
 
-* `HighestTagBaseVersionStrategy` - Finds the highest reachable tag from the
-    current branch
-* `VersionInBranchBaseVersionStrategy` - Extracts version information from the
+* `TaggedCommit` - Extracts version information from all tags on the branch which are valid, and not newer than the current commit.
+* `VersionInBranchName` - Extracts version information from the
     branch name (e.g., `release/3.0.0` will find `3.0.0`)
-* `ConfigNextVersionBaseVersionStrategy` - Returns the version from the
+* `ConfiguredNextVersion` - Returns the version from the
     GitVersion.yaml file
-* `MergeMessageBaseVersionStrategy` - Finds version numbers from merge messages
+* `MergeMessage` - Finds version numbers from merge messages
     (e.g., `Merge 'release/3.0.0' into 'main'` will return `3.0.0`)
-* `FallbackBaseVersionStrategy` - Always returns 0.0.0 and will be used for
+* `Fallback` - Always returns 0.0.0 and will be used for
     calculating the next version which is dependent on the increment strategy of
  the effected branch (e.g. on main the next version is 0.0.1 or on develop it is 0.1.0)
+* `TrackReleaseBranches` - TODO: Document this
+* `Mainline` - TODO: Document this
 
 Each strategy needs to return an instance of `BaseVersion` which has the
 following properties:
 
 * `Source` - Description of the source (e.g., `Merge message 'Merge 'release/3.0.0' into 'main'`)
 * `ShouldIncrement` - Some strategies should have the version incremented,
-    others do not (e.g., `ConfigNextVersionBaseVersionStrategy` returns false,
-    `HighestTagBaseVersionStrategy` returns true)
+    others do not (e.g., `ConfiguredNextVersion` returns false,
+    `TaggedCommit` returns true)
 * `SemanticVersion` - SemVer of the base version strategy
 * `BaseVersionSource` - SHA hash of the source. Commits will be counted from
-    this hash. Can be null (e.g., `ConfigNextVersionBaseVersionStrategy` returns
+    this hash. Can be null (e.g., `ConfiguredNextVersion` returns
     null).
 * `BranchNameOverride` - When `useBranchName` or `{BranchName}` is used in the
     tag configuration, this allows the branch name to be changed by a base version.
-    `VersionInBranchBaseVersionStrategy` uses this to strip out anything before the
+    `VersionInBranchName` uses this to strip out anything before the
     first `-` or `/.` so `foo` ends up being evaluated as `foo`. If in doubt, just
     use null.