Merge branch 'release/0.9.0'

* release/0.9.0: (50 commits)
  (build) Add standard GRM configuration file
  (build) Update to latest Posix Bootstrapper
  (maint) Update Cake Bootstrappers
  (GH-141) Update default target
  (GH-141) Start using latest Cake.Recipe
  (GH-141) Add new NuGet Metadata
  Revert "(GH-141) Remove NuGet nuspec file"
  (GH-141) Add additional NuGet Metadata
  (GH-141) Remove NuGet nuspec file
  (GH-136) Fix default value
  (doc) Markdown lint fixes
  (GH-134) Add docs about new config options
  (doc) Markdown lint fixes
  (GH-134) Add new config options
  (doc) Add configuration for markdownlint
  (doc) Markdown lint fixes
  (doc) Markdown lint fixes
  (doc) Markdown lint fixes
  (doc) Markdown lint fixes
  (doc) Markdown lint fixes
  ...

.appveyor.yml

@@ -1,13 +1,13 @@
 #---------------------------------#
 #  Build Image                    #
 #---------------------------------#
-image: Visual Studio 2017
+image: Visual Studio 2019
 
 #---------------------------------#
 #  Build Script                   #
 #---------------------------------#
 build_script:
-  - ps: .\build.ps1 -Target AppVeyor
+  - ps: .\build.ps1 -Target ContinuousIntegration
 
 # Tests
 test: off
@@ -21,26 +21,9 @@ branches:
     - develop
     - master
 
-#---------------------------------#
-#  notifications configuration    #
-#---------------------------------#
-notifications:
-  - provider: Webhook
-    url: https://webhooks.gitter.im/e/a72ea926ecc08de68e71
-    on_build_success: true
-    on_build_failure: true
-    on_build_status_changed: true
-
 #---------------------------------#
 #  Build Cache                    #
 #---------------------------------#
 cache:
 - Source\packages -> Source\**\packages.config
-- Tools -> build.ps1
-
-#---------------------------------#
-#  Skip builds for doc changes    #
-#---------------------------------#
-skip_commits:
-  # Regex for matching commit message
-  message: /(doc).*/
+- Tools -> recipe.cake

.markdownlint.json

@@ -0,0 +1,3 @@
+{
+    "MD026": false
+}

.vscode/settings.json

@@ -0,0 +1,13 @@
+{
+    "editor.rulers": [80],
+    "cSpell.words": [
+        "addasset",
+        "buildartifacts",
+        "choco",
+        "gitreleasemanager",
+        "nupkg",
+        "psake",
+        "releasenotes",
+        "showconfig"
+    ]
+}

COMMITTERS.md

@@ -1,5 +1,4 @@
-Committing
-==========
+# Committing
 
 We like to see folks contributing to GitReleaseManager. If you are a committer, we'd like to see you help from time to time with triage and the pull request process.
 
@@ -17,25 +16,26 @@ Please be VERY familiar with [CONTRIBUTING](https://github.com/GitTools/GitRelea
 
 ## Review Process
 
-#### Receive new PR (pull request)
+### Receive new PR (pull request)
 
- * A contributor sends a pull request (usually against master).
- * A committer typically reviews it within a week or less to determine the feasibility of the changes.
+* A contributor sends a pull request (usually against master).
+* A committer typically reviews it within a week or less to determine the feasibility of the changes.
 
-#### Initial PR Review
+### Initial PR Review
 
- * Did the user create a branch with these changes? If it is on their master, please ask them to review [CONTRIBUTING](https://github.com/GitTools/GitReleaseManager/blob/develop/CONTRIBUTING.md).
- * Did the user reformat files and they should not have? Was is just white-space? You can try adding [?w=1](https://github.com/blog/967-github-secrets) to the URL on GitHub.
- * Are there tests? We really want any new contributions to contain tests so unless the committer believes this code really needs to be in the code base and is willing to write the tests, then we need to ask the contributor to make a good faith effort in adding test cases. Ask them to review the [contributing document](https://github.com/GitTools/GitReleaseManager/blob/develop/CONTRIBUTING.md) and provide tests. **Note:** Some commits may be refactoring which wouldn't necessarily add additional test sets.
- * Is the code documented properly? Does this additional set of changes require changes to the [documentation](http://gitreleasemanager.readme.io/)?
- * Was this code warranted? Did the contributor follow the process of gaining approval for big change sets? If not please have them review the [contributing document](https://github.com/GitTools/GitReleaseManager/blob/develop/CONTRIBUTING.md) and ask them to follow up in the Chat Room.
+* Did the user create a branch with these changes? If it is on their master, please ask them to review [CONTRIBUTING](https://github.com/GitTools/GitReleaseManager/blob/develop/CONTRIBUTING.md).
+* Did the user reformat files and they should not have? Was is just white-space? You can try adding [?w=1](https://github.com/blog/967-github-secrets) to the URL on GitHub.
+* Are there tests? We really want any new contributions to contain tests so unless the committer believes this code really needs to be in the code base and is willing to write the tests, then we need to ask the contributor to make a good faith effort in adding test cases. Ask them to review the [contributing document](https://github.com/GitTools/GitReleaseManager/blob/develop/CONTRIBUTING.md) and provide tests. **Note:** Some commits may be refactoring which wouldn't necessarily add additional test sets.
+* Is the code documented properly? Does this additional set of changes require changes to the [documentation](http://gittools.github.io/GitReleaseManager/docs/)?
+* Was this code warranted? Did the contributor follow the process of gaining approval for big change sets? If not please have them review the [contributing document](https://github.com/GitTools/GitReleaseManager/blob/develop/CONTRIBUTING.md) and ask them to follow up in the Chat Room.
 
-#### Review the Code
-  * Does the code meet the naming conventions and formatting (need link)?
-  * Is the code sound? Does it read well? Can you understand what it is doing without having to execute it? Principal of no clever hacks (need link).
-  * Does the code do what the purpose of the pull request is for?
+### Review the Code
 
-#### Accepting a PR
+* Does the code meet the naming conventions and formatting (need link)?
+* Is the code sound? Does it read well? Can you understand what it is doing without having to execute it? Principal of no clever hacks (need link).
+* Does the code do what the purpose of the pull request is for?
+
+### Accepting a PR
 
 Once you have reviewed the initial items, and are not waiting for additional feedback or work by the contributor, give the thumbs up that it is ready for the next part of the process (merging).
 

CONTRIBUTING.md

@@ -1,52 +1,51 @@
-Contributors
-============
+# Contributors
 
 ## Contributing Process
 
 ### Get Buyoff Or Find Open Community Issues/Features
 
- * Through GitHub, or through the [Chat Room](https://gitter.im/GitTools/GitReleaseManager) (preferred), you talk about a feature you would like to see (or a bug), and why it should be in GitReleaseManager.
-   * If approved through the Chat Room, ensure the accompanying GitHub issue is created with information and a link back to the Chat Room discussion.
- * Once you get a nod you can start on the feature.
- * Alternatively, if a feature is on the issues list with the [community tag](https://github.com/GitTools/GitReleaseManager/labels/Community), it is open for a patch. You should comment that you are signing up for it on the issue so someone else doesn't also sign up for the work.
+* Through GitHub, or through the [Chat Room](https://gitter.im/GitTools/GitReleaseManager) (preferred), you talk about a feature you would like to see (or a bug), and why it should be in GitReleaseManager.
+  * If approved through the Chat Room, ensure the accompanying GitHub issue is created with information and a link back to the Chat Room discussion.
+* Once you get a nod you can start on the feature.
+* Alternatively, if a feature is on the issues list with the [community tag](https://github.com/GitTools/GitReleaseManager/labels/Community), it is open for a patch. You should comment that you are signing up for it on the issue so someone else doesn't also sign up for the work.
 
 ### Set Up Your Environment
 
- * You create, or update, a fork of GitTools/GitReleaseManager under your GitHub account.
- * From there you create a branch named specific to the feature.
- * In the branch you do work specific to the feature.
- * Please also observe the following:
-    * No reformatting
-    * No changing files that are not specific to the feature
-    * More covered below in the **Prepare commits** section.
- * Test your changes and please help us out by updating and implementing some automated tests. It is recommended that all contributors spend some time looking over the tests in the source code. You can't go wrong emulating one of the existing tests and then changing it specific to the behavior you are testing.
- * Please do not update your branch from the master unless we ask you to. See the responding to feedback section below.
+* You create, or update, a fork of GitTools/GitReleaseManager under your GitHub account.
+* From there you create a branch named specific to the feature.
+* In the branch you do work specific to the feature.
+* Please also observe the following:
+  * No reformatting
+  * No changing files that are not specific to the feature
+  * More covered below in the **Prepare commits** section.
+* Test your changes and please help us out by updating and implementing some automated tests. It is recommended that all contributors spend some time looking over the tests in the source code. You can't go wrong emulating one of the existing tests and then changing it specific to the behavior you are testing.
+* Please do not update your branch from the master unless we ask you to. See the responding to feedback section below.
 
 ### Prepare Commits
 
 This section serves to help you understand what makes a good commit.
 
 A commit should observe the following:
 
- * A commit is a small logical unit that represents a change.
- * Should include new or changed tests relevant to the changes you are making.
- * No unnecessary whitespace. Check for whitespace with `git diff --check` and `git diff --cached --check` before commit.
- * You can stage parts of a file for commit.
+* A commit is a small logical unit that represents a change.
+* Should include new or changed tests relevant to the changes you are making.
+* No unnecessary whitespace. Check for whitespace with `git diff --check` and `git diff --cached --check` before commit.
+* You can stage parts of a file for commit.
 
 A commit message should observe the following:
 
-  * The first line of the commit message should be a short description around 50 characters in length and be prefixed with the GitHub issue it refers to with parentheses surrounding that. If the GitHub issue is #25, you should have `(GH-25)` prefixed to the message.
-  * If the commit is about documentation, the message should be prefixed with `(doc)`.
-  * If it is a trivial commit or one of formatting/spaces fixes, it should be prefixed with `(maint)`.
-  * After the subject, skip one line and fill out a body if the subject line is not informative enough.
-  * The body:
-    * Should indent at `72` characters.
-    * Explains more fully the reason(s) for the change and contrasts with previous behavior.
-    * Uses present tense. "Fix" versus "Fixed".
+* The first line of the commit message should be a short description around 50 characters in length and be prefixed with the GitHub issue it refers to with parentheses surrounding that. If the GitHub issue is #25, you should have `(GH-25)` prefixed to the message.
+* If the commit is about documentation, the message should be prefixed with `(doc)`.
+* If it is a trivial commit or one of formatting/spaces fixes, it should be prefixed with `(maint)`.
+* After the subject, skip one line and fill out a body if the subject line is not informative enough.
+* The body:
+  * Should indent at `72` characters.
+  * Explains more fully the reason(s) for the change and contrasts with previous behavior.
+  * Uses present tense. "Fix" versus "Fixed".
 
 A good example of a commit message is as follows:
 
-```
+```shell
 (GH-7) Installation Adds All Required Folders
 
 Previously the installation script worked for the older version of
@@ -62,15 +61,15 @@ choco client properly.
 
 Prerequisites:
 
- * You are making commits in a feature branch.
- * All specs should be passing.
+* You are making commits in a feature branch.
+* All specs should be passing.
 
 Submitting PR:
 
- * Once you feel it is ready, submit the pull request to the `GitTools/GitReleaseManager` repository against the ````develop```` branch ([more information on this can be found here](https://help.github.com/articles/creating-a-pull-request)).
- * In the pull request, outline what you did and point to specific conversations (as in URLs) and issues that you are are resolving. This is a tremendous help for us in evaluation and acceptance.
- * Once the pull request is in, please do not delete the branch or close the pull request (unless something is wrong with it).
- * One of the Team members, or one of the committers, will evaluate it within a reasonable time period (which is to say usually within 2-4 weeks). Some things get evaluated faster or fast tracked. We are human and we have active lives outside of open source so don't fret if you haven't seen any activity on your pull request within a month or two. We don't have a Service Level Agreement (SLA) for pull requests. Just know that we will evaluate your pull request.
+* Once you feel it is ready, submit the pull request to the `GitTools/GitReleaseManager` repository against the ````develop```` branch ([more information on this can be found here](https://help.github.com/articles/creating-a-pull-request)).
+* In the pull request, outline what you did and point to specific conversations (as in URLs) and issues that you are are resolving. This is a tremendous help for us in evaluation and acceptance.
+* Once the pull request is in, please do not delete the branch or close the pull request (unless something is wrong with it).
+* One of the Team members, or one of the committers, will evaluate it within a reasonable time period (which is to say usually within 2-4 weeks). Some things get evaluated faster or fast tracked. We are human and we have active lives outside of open source so don't fret if you haven't seen any activity on your pull request within a month or two. We don't have a Service Level Agreement (SLA) for pull requests. Just know that we will evaluate your pull request.
 
 ### Respond to Feedback on Pull Request
 
@@ -80,18 +79,18 @@ If we have comments or questions when we do evaluate it and receive no response,
 
 Sometimes we may need you to rebase your commit against the latest code before we can review it further. If this happens, you can do the following:
 
- * `git fetch upstream` (upstream would be the mainstream repo or `GitTools/GitReleaseManager` in this case)
- * `git checkout develop`
- * `git rebase upstream/develop`
- * `git checkout your-branch`
- * `git rebase develop`
- * Fix any merge conflicts
- * `git push origin your-branch` (origin would be your GitHub repo or `your-github-username/GitReleaseManager` in this case). You may need to `git push origin your-branch --force` to get the commits pushed. This is generally acceptable with topic branches not in the mainstream repository.
+* `git fetch upstream` (upstream would be the mainstream repo or `GitTools/GitReleaseManager` in this case)
+* `git checkout develop`
+* `git rebase upstream/develop`
+* `git checkout your-branch`
+* `git rebase develop`
+* Fix any merge conflicts
+* `git push origin your-branch` (origin would be your GitHub repo or `your-github-username/GitReleaseManager` in this case). You may need to `git push origin your-branch --force` to get the commits pushed. This is generally acceptable with topic branches not in the mainstream repository.
 
 The only reasons a pull request should be closed and resubmitted are as follows:
 
-  * When the pull request is targeting the wrong branch (this doesn't happen as often).
-  * When there are updates made to the original by someone other than the original contributor. Then the old branch is closed with a note on the newer branch this supersedes #github_number.
+* When the pull request is targeting the wrong branch (this doesn't happen as often).
+* When there are updates made to the original by someone other than the original contributor. Then the old branch is closed with a note on the newer branch this supersedes #github_number.
 
 ## Other General Information
 

GitReleaseManager.yaml

@@ -0,0 +1,16 @@
+issue-labels-include:
+- Breaking change
+- Feature
+- Bug
+- Improvement
+- Documentation
+- security
+issue-labels-exclude:
+- Build
+issue-labels-alias:
+    - name:    Documentation
+      header:  Documentation
+      plural:  Documentation
+    - name:    security
+      header:  Security
+      plural:  Security