(doc) Fix internal links

Some had to be updated, others needed to have the .md removed from the
link.

Author: gep13

docs/input/docs/build-server-support/build-server-support.md

@@ -21,7 +21,7 @@ instance if you are running in TeamCity after you run
 `GitVersion /output buildserver` you will have the `%system.GitVersion.SemVer%`
 available for you to use.
 
-When running in MSBuild either from the [MSBuild Task](/usage/msbuild-task) or
+When running in MSBuild either from the [MSBuild Task](../usage/msbuild-task) or
 by using the `/proj myproject.sln` parameter, GitVersion will make the MSBuild
 variables available in the format `$(GitVersion_SemVer)`.
 

docs/input/docs/build-server-support/build-server/azure-devops.md

@@ -17,7 +17,7 @@ task into your TFS or Azure DevOps Pipeline instance.
 1. Add the [GitVersionTask](https://www.nuget.org/packages/GitVersionTask/)
 NuGet package to your projects.
 
-See [MSBuild Task](/usage/msbuild-task) for further instructions how to use the
+See [MSBuild Task](../../usage/msbuild-task) for further instructions how to use the
 MS Build Task.
 
 ### Using GitVersion with the Command Line build step
@@ -122,7 +122,7 @@ To use these variables you can just refer to them using the standard variable
 syntax. For instance `$(GitVersion.NuGetVersion)` in your nuget pack task to set
 the version number. Since update 1 there are no known limitations.
 
-See [Variables](/more-info/variables/) for an overview of available variables.
+See [Variables](../../more-info/variables) for an overview of available variables.
 
 #### Using GitVersion variables in build name
 
@@ -139,7 +139,7 @@ If GitVersion does not find any substitutions it will just default to using `Ful
 work correctly if you
 use GitVersion variables as well due to the delayed expansion of the GitVersion
 vars. Instead, you might be able to use `$(GitVersion_BuildMetaData)` to achieve
-a similar result.  See [Variables](/more-info/variables/) for more info on the
+a similar result.  See [Variables](../../more-info/variables) for more info on the
 variables.
 
 #### Known limitations

docs/input/docs/build-server-support/build-server/gitlab.md

@@ -3,5 +3,5 @@ Order: 50
 Title: GitLab CI
 ---
 
-To use GitVersion with GitLab CI, either use the [MSBuild Task](/usage/msbuild-task)
+To use GitVersion with GitLab CI, either use the [MSBuild Task](../../usage/msbuild-task)
 or put the GitVersion executable in your runner's `PATH`.

docs/input/docs/build-server-support/build-server/octopus-deploy.md

@@ -6,7 +6,7 @@ Title: Octopus Deploy
 While not a build server, there are a few things to consider when using Octopus
 Deploy with GitVersion.
 
- GitVersion follows [continuous delivery](../../reference/continuous-delivery.md)
+ GitVersion follows [continuous delivery](../../reference/versioning-modes/continuous-delivery)
  versioning by default. This means builds will keep producing *the same version*
  with just metadata differing. For example, when you start a new release (say
  `1.0.0`) with git flow, the branch will start with a semver like
@@ -168,7 +168,7 @@ if ($versionInfo.PreReleaseTag -eq '')
 }
 ```
 
-### Configure GitVersion to [increment per commit](../../more-info/incrementing-per-commit.md)
+### Configure GitVersion to [increment per commit](../../more-info/incrementing-per-commit)
 
 As mentioned above, this means you will burn multiple versions per release. This
 might not be an issue for you, but can confuse consumers of your library as the

docs/input/docs/build-server-support/build-server/teamcity.md

@@ -57,7 +57,7 @@ GitVersion. Server side checkout sends just the files to the agent and not the
 actual .git folder. Dynamic repositories will clone your repo into a temp folder
 and use it to calculate version information.
 
-See [dynamic repositories](../../more-info/dynamic-repositories.md) for more info.
+See [dynamic repositories](../../more-info/dynamic-repositories) for more info.
 
 ### Output
 

docs/input/docs/configuration.md

@@ -83,7 +83,7 @@ skip updating the `AssemblyFileVersion` while still updating the
 
 ### assembly-file-versioning-format
 
-Set this to any of the available [variables](/more-info/variables) in
+Set this to any of the available [variables](./more-info/variables) in
 combination (but not necessary) with a process scoped environment variable. It
 overwrites the value of `assembly-file-versioning-scheme`. To reference an
 environment variable, use `env:` Example Syntax #1:
@@ -106,15 +106,15 @@ the value of `assembly-versioning-scheme`.
 
 ### assembly-informational-format
 
-Set this to any of the available [variables](/more-info/variables) to change the
+Set this to any of the available [variables](./more-info/variables) to change the
 value of the `AssemblyInformationalVersion` attribute. Default set to
 `{InformationalVersion}`. It also supports string interpolation
 (`{MajorMinorPatch}+{BranchName}`)
 
 ### mode
 
 Sets the `mode` of how GitVersion should create a new version. Read more at
-[versioning mode](/reference/versioning-mode.md).
+[versioning modes](./reference/versioning-modes).
 
 ### increment
 
@@ -166,19 +166,19 @@ none` and `+semver: skip`
 ### legacy-semver-padding
 
 The number of characters to pad `LegacySemVer` to in the `LegacySemVerPadded`
-[variable](/more-info/variables). Is default set to `4`, which will pad the
+[variable](./more-info/variables). Is default set to `4`, which will pad the
 `LegacySemVer` value of `3.0.0-beta1` to `3.0.0-beta0001`.
 
 ### build-metadata-padding
 
 The number of characters to pad `BuildMetaData` to in the `BuildMetaDataPadded`
-[variable](/more-info/variables). Is default set to `4`, which will pad the
+[variable](./more-info/variables). Is default set to `4`, which will pad the
 `BuildMetaData` value of `1` to `0001`.
 
 ### commits-since-version-source-padding
 
 The number of characters to pad `CommitsSinceVersionSource` to in the
-`CommitsSinceVersionSourcePadded` [variable](/more-info/variables). Is default
+`CommitsSinceVersionSourcePadded` [variable](./more-info/variables). Is default
 set to `4`, which will pad the `CommitsSinceVersionSource` value of `1` to
 `0001`.
 
@@ -481,7 +481,7 @@ default support/ and master are mainlines.
 ### pre-release-weight
 
 Provides a way to translate the `PreReleaseLabel`
-([variables](/more-info/variables)) to a numeric value in order to avoid version
+([variables](./more-info/variables)) to a numeric value in order to avoid version
 collisions across different branches. For example, a release branch created
 after "1.2.3-alpha.55" results in "1.2.3-beta.1" and thus e.g. "1.2.3-alpha.4"
 and "1.2.3-beta.4" would have the same file version: "1.2.3.4". One of the ways

docs/input/docs/examples.md

@@ -31,13 +31,13 @@ following branch types ootb:
 - release/
 
 If you have other branch types GitVersion is entirely configuration driven, so
-check out the [Configuration](configuration.md) section of the readme to
+check out the [Configuration](configuration) section of the readme to
 understand how to make GitVersion work for you.
 
 ## GitFlow
 
-[See GitFlow Examples](git-branching-strategies/gitflow-examples.md)
+[See GitFlow Examples](git-branching-strategies/gitflow-examples)
 
 ## GitHubFlow
 
-[See GitHubFlow Examples](git-branching-strategies/githubflow-examples.md)
+[See GitHubFlow Examples](git-branching-strategies/githubflow-examples)

docs/input/docs/faq.md

@@ -6,19 +6,19 @@ Title: FAQ
 ## Why is my version not incrementing?
 
 GitVersion calculates the semantic version, this will only change once per
-*release*. Read more at [version increments](more-info/version-increments.md)
+*release*. Read more at [version increments](more-info/version-increments)
 
 ## I'm using Octopus deploy
 
 Because Octopus deploy cannot have the same version of a package to a NuGet
 feed. There is no magic solution to this, but you can read more about your
-options at [octopus deploy](build-server-support/build-server/octopus-deploy.md).
+options at [octopus deploy](build-server-support/build-server/octopus-deploy).
 
 ## How can GitVersion run for a shallow clone or checkout on server working directories
 
 GitVersion needs a proper git repository to run, some build servers do not do a
 proper clone which can cause issues. GitVersion has a feature called
-[dynamic repositories](more-info/dynamic-repositories.md) which solves this by
+[dynamic repositories](more-info/dynamic-repositories) which solves this by
 cloning the repository and working against that clone instead of the working
 directory.
 
@@ -27,7 +27,7 @@ directory.
 Not a problem, we have a quick introduction to SemVer which can be a good primer
 to read before reading [SemVer.org](http://semver.org)
 
-Read more at [intro to semver](reference/intro-to-semver.md)
+Read more at [intro to semver](reference/intro-to-semver)
 
 ## I can't use the build number for NuGet
 

docs/input/docs/git-branching-strategies/gitflow-examples.md

@@ -4,13 +4,13 @@ Title: GitFlow Examples
 ---
 
 These examples are using the *default* configuration with GitVersion. Which is
-[continuous deployment](../reference/continuous-deployment.md) mode for
-`develop` and [continuous delivery](../reference/continuous-delivery.md) mode
+[continuous deployment](../reference/versioning-modes/continuous-deployment) mode for
+`develop` and [continuous delivery](../reference/versioning-modes/continuous-delivery) mode
 for all other branches.
 
 This default configuration allows you to publish CI builds from develop to a CI
 MyGet feed, or another CI feed. Then all other branches are manually released
-then tagged. Read more about this at [version increments](../more-info/version-increments.md).
+then tagged. Read more about this at [version increments](../more-info/version-increments).
 
 ## Feature Branches
 
@@ -82,4 +82,4 @@ patch *will not* automatically bump, meaning you have to use hotfix branches.
 
 ## To Update/Contribute
 
-See [creating/updating examples](creating-updating-examples.md)
+See [creating/updating examples](creating-updating-examples)

docs/input/docs/git-branching-strategies/githubflow.md

@@ -9,15 +9,15 @@ are much better off with a simpler workflow.
 
 GitHubFlow is in a nutshell:
 
-1. Update master to latest [upstream](../reference/git-setup.md#upstream) code
+1. Update master to latest [upstream](../reference/git-setup#upstream) code
 1. Create a feature branch `git checkout -b myFeatureBranch`
 1. Do the feature/work
-1. Push feature branch to [origin](../reference/git-setup.md#origin)
+1. Push feature branch to [origin](../reference/git-setup#origin)
 1. Create pull request from origin/<featureBranch> -> upstream/master
 1. Review, fix raised comments, merge your PR or even better, get someone else to.
 
 The main rule of GitHub Flow is that master should *always* be deployable.
-GitHub Flow allows and encourages [continuous delivery](../reference/continuous-delivery.md).
+GitHub Flow allows and encourages [continuous delivery](../reference/versioning-modes/continuous-delivery).
 
 ## Resources
 

docs/input/docs/git-branching-strategies/overview.md

@@ -17,18 +17,18 @@ associated workflows then you will likely lose work at some point. At the start
 of any project I recommend picking a branching strategy and making sure your
 whole team understands it.
 
-As mentioned above the GitVersion docs cover [GitHubFlow](githubflow.md) and
-[GitFlow](gitflow.md).
+As mentioned above the GitVersion docs cover [GitHubFlow](githubflow) and
+[GitFlow](gitflow).
 
 ### GitHubFlow
 
 GitHubFlow is a simple and powerful branching strategy. It is what GitHub uses
 and the branching strategy most open source projects use.
 
- - [Mainline development](../reference/mainline-development.md) on `master`
- - Work on [feature branches](../reference/feature-branches.md), merge into
-`master` via [pull requests](../reference/pull-requests.md)
- - Works well for [continuous delivery](../reference/continuous-delivery.md)
+ - [Mainline development](../reference/versioning-modes/mainline-development) on `master`
+ - Work on [feature branches](../reference/feature-branches), merge into
+`master` via [pull requests](../reference/pull-requests)
+ - Works well for [continuous delivery](../reference/versioning-modes/continuous-delivery)
  - Does not have a way to manage/maintain old releases
  - Only allows working on a single release at a time
 
@@ -55,4 +55,4 @@ fixes/smaller features are still going into the current release
 
 But if you do not have a good reason to go with GitFlow, then start with
 GitHubFlow. It is a far simpler model and if you end up needing GitFlow later,
-it is [easy to convert](converting-to-gitflow.md)
+it is [easy to convert](converting-to-gitflow)

docs/input/docs/index.md

@@ -30,7 +30,7 @@ This trips a lot of people up, by default GitVersion *does not* increment the
 SemVer every commit. This means that you will get multiple builds producing the
 *same version* of your application.
 
-Read more at [version increments](more-info/version-increments.md)
+Read more at [version increments](more-info/version-increments)
 
 ### Version sources
 
@@ -44,15 +44,15 @@ There are a number of sources GitVersion can get its versions from, they include
 increments so does develop)
 - GitVersion.yml file (e.g `next-version: 2.0.0`)
 
-Read more at [version sources](more-info/version-sources.md)
+Read more at [version sources](more-info/version-sources)
 
 ## Configuration
 
 GitVersion v3 was rewritten to be very configuration driven rather than
 hardcoding git workflows into it. This has made it a lot more flexible.
 Configuration options can be set globally or per branch.
 
-Read more about [configuration](configuration.md)
+Read more about [configuration](configuration)
 
 ## Output Variables
 
@@ -73,7 +73,7 @@ integrate into your project and write out variables to your build server if it's
 running on one. The exe offers more options and works for .NET projects as well
 as other project types.
 
-Read more about [using GitVersion](usage/usage.md)
+Read more about [using GitVersion](usage/usage)
 
 ## Supported languages and frameworks
 

docs/input/docs/more-info/how-it-works.md

@@ -7,7 +7,7 @@ GitVersion v3 works very differently to v2. Version 2 had knowledge of both
 GitFlow and GitHubFlow hard coded into it, with each branch having it's own
 class which calculated the version for that branch type.
 
-v3 is driven by [configuration](../configuration.md), meaning most of the
+v3 is driven by [configuration](../configuration), meaning most of the
 behaviors in GitVersion can be tweaked to work the way you want. This also makes
 it *much* more predictable and easier to diagnose when odd things are happening.
 

docs/input/docs/more-info/version-increments.md

@@ -50,7 +50,7 @@ feed will see the alpha packages.
 
 ### 2. Octopus deploy
 
-See [Octopus deploy](../build-server-support/build-server/octopus-deploy.md)
+See [Octopus deploy](../build-server-support/build-server/octopus-deploy)
 
 ## Manually incrementing the version
 

docs/input/docs/reference/intro-to-semver.md

@@ -28,4 +28,4 @@ For a more complete explaination check out [semver.org](http://semver.org) which
 ## SemVer in GitVersion
 GitVersion makes it easy to follow semantic versioning in your library by automatically calculating the next semantic version which your library/application is likely to use. In [GitFlow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/) the develop branch will bump the *minor* when master is tagged, while [GitHubFlow](https://guides.github.com/introduction/flow/) will bump the *patch*.
 
-Because one size does not always fit all, GitVersion provides many [Variables](../more-info/variables.md) for you to use which contain different variations of the version. For example SemVer will be in the format `{major}.{minor}.{patch}-{tag}`, but `FullSemVer` will also include build metadata: `{major}.{minor}.{patch}-{tag}+{buildmetadata}`
+Because one size does not always fit all, GitVersion provides many [Variables](../more-info/variables) for you to use which contain different variations of the version. For example SemVer will be in the format `{major}.{minor}.{patch}-{tag}`, but `FullSemVer` will also include build metadata: `{major}.{minor}.{patch}-{tag}+{buildmetadata}`

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

@@ -28,16 +28,16 @@ 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-development.md) model means that every merged
+[mainline development](mainline-development) 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.md).
+`develop`, which is set up with [Continuous Deployment](continuous-deployment).
 To change the mode to Continuous Delivery, change your
-[configuration](../configuration.md) to:
+[configuration](../../configuration) to:
 
 ```yaml
 mode: ContinuousDelivery

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

@@ -15,18 +15,18 @@ 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-development.md).
+[Mainline Development](mainline-development).
 
 ### Usage
 
 By default GitVersion is set up to do Continuous Deployment versioning on the
 `develop` branch, but for all other branches,
-[Continuous Delivery](continuous-delivery.md) is the default mode. From version
-3 of GitVersion this behavior is [configurable](../configuration.md).
+[Continuous Delivery](continuous-delivery) is the default mode. From version
+3 of GitVersion this behavior is [configurable](../../configuration).
 
 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.md) from
+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:

docs/input/docs/reference/versioning-modes/mainline-development.md

@@ -4,7 +4,7 @@ Title: Mainline Development
 ---
 
 Mainline Development is enabled when using
-[GitHubFlow](../git-branching-strategies/githubflow.md) or any other strategy
+[GitHubFlow](../../git-branching-strategies/githubflow) or any other strategy
 where you develop on `master`. The main rule of mainline development is that
 **master is always in a state that it could be deployed to production**. This
 means that pull requests should not be merged until they are ready to go out.
@@ -44,17 +44,17 @@ Here is an example of what mainline development looks like:
 ![Mainline mode](../../img/mainline-mode.png)
 
 **WARNING:** This approach can slow down over time, we recommend to tag
-intermitently (maybe for minor or major releases) because then GitVersion
+intermittently (maybe for minor or major releases) because then GitVersion
 will start the version calculation from that point. Much like a snapshot in an
 event sourced system. We will probably add in warnings to tag when things are
 slowing down.
 
 ## Usage
-By default GitVersion is set up to do [Continuous Delivery](continuous-delivery.md)
+By default GitVersion is set up to do [Continuous Delivery](continuous-delivery)
 versioning on all branches but `develop` (which does
-[Continuous Deployment](continuous-deployment.md) by default). To change the
-[versioning mode](versioning-mode.md) to Mainline Development, just
-change the [configuration](../configuration.md) as such:
+[Continuous Deployment](continuous-deployment) by default). To change the
+[versioning mode](versioning-mode) to Mainline Development, just
+change the [configuration](../../configuration) as such:
 
 ```yaml
 mode: Mainline