Update documentation to use alpha prefix

Author: Pascal Berger

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

@@ -8,7 +8,7 @@ Feature branches will take the feature branch name and use that as the pre-relea
 
 ![GitFlow](img/05119d0cd4ecaaefff94_feature-branch.png)
 
-Notice after the feature branch is merged, the version on `develop` is `1.3.0-unstable.3`. This is due to `develop` running in *continuous deployment* mode. If you configured `develop` to use *continuous delivery* the version would still be `1.3.0-unstable.1` and you would have to use release tags to increment the `unstable.1`.
+Notice after the feature branch is merged, the version on `develop` is `1.3.0-alpha.3`. This is due to `develop` running in *continuous deployment* mode. If you configured `develop` to use *continuous delivery* the version would still be `1.3.0-alpha.1` and you would have to use release tags to increment the `alpha.1`.
 
 You can see the different on the feature branch itself, notice the version is the same before and after the commit on the feature branch? Only the metadata has changed. If you released the feature branch artifacts then tagged the commit, the following commit would increase to `-beta.2`.
 

docs/git-branching-strategies/gitflow.md

@@ -52,12 +52,12 @@ Long version:
 * major: `masterMergeVersion.Major`
 * minor: `masterMergeVersion.Minor + 1` (0 if the override above is used)
 * patch: 0
-* pre-release: `unstable{n}` where n = how many commits `develop` is in front of `masterVersionCommit.Date` ('0' padded to 4 characters)
+* pre-release: `alpha.{n}` where n = how many commits `develop` is in front of `masterVersionCommit.Date` ('0' padded to 4 characters)
 
 Long version:  
 
     {major}.{minor}.{patch}-{pre-release} Branch:'{branchName}' Sha:'{sha}'
-    1.2.3-unstable645 Branch:'develop' Sha:'a682956dccae752aa24597a0f5cd939f93614509'
+    1.2.3-alpha.645 Branch:'develop' Sha:'a682956dccae752aa24597a0f5cd939f93614509'
 
 ### Hotfix branches
 
@@ -108,13 +108,13 @@ TODO: feature branches cannot start with a SemVer. to stop people from create br
 * major: `masterMergeVersion.Major`
 * minor: `masterMergeVersion.Minor + 1` (0 if the override above is used)
 * patch: 0
-* pre-release: `unstable.feature-{n}` where n = First 8 characters of the commit SHA of the first commit
+* pre-release: `alpha.feature-{n}` where n = First 8 characters of the commit SHA of the first commit
 
 
 Long version:  
 
     {major}.{minor}.{patch}-{pre-release} Branch:'{branchName}' Sha:'{sha}'
-    1.2.3-unstable.feature-a682956d Branch:'feature1' Sha:'a682956dccae752aa24597a0f5cd939f93614509'
+    1.2.3-alpha.feature-a682956d Branch:'feature1' Sha:'a682956dccae752aa24597a0f5cd939f93614509'
 
 ### Pull-request branches
 
@@ -125,7 +125,7 @@ Branch naming convention: anything except `master`, `develop`, `release-{n}`, or
 * major: `masterMergeVersion.Major`
 * minor: `masterMergeVersion.Minor + 1` (0 if the override above is used)
 * patch: 0
-* pre-release: `unstable.pull{n}` where n = the pull request number  ('0' padded to 4 characters)
+* pre-release: `alpha.pull{n}` where n = the pull request number  ('0' padded to 4 characters)
 
 ## Nightly Builds
 

docs/more-info/version-increments.md

@@ -12,9 +12,9 @@ This causes problems for people as NuGet and other package managers do not suppo
 There are a few ways to handle this problem depending on what your requirements are:
 
 ### 1. GitFlow
-If you are using GitFlow then builds off the `develop` branch will actually *increment on every commit*. This is known in GitVersion as *continuous deployment mode*. By default `develop` builds are tagged with the `unstable` pre-release tag. This is so they are sorted higher than release branches.
+If you are using GitFlow then builds off the `develop` branch will actually *increment on every commit*. This is known in GitVersion as *continuous deployment mode*. By default `develop` builds are tagged with the `alpha` pre-release tag. This is so they are sorted higher than release branches.
 
-If you need to consume packages built from develop, we recommend publishing these packages to a separate NuGet feed as an alpha channel. That way you can publish beta/release candidate builds and only people who opt into the alpha feed will see the unstable packages.
+If you need to consume packages built from develop, we recommend publishing these packages to a separate NuGet feed as an alpha channel. That way you can publish beta/release candidate builds and only people who opt into the alpha feed will see the alpha packages.
 
 ### 2. Octopus deploy
 See [Octopus deploy](../build-server-support/build-server/octopus-deploy.md)