Add RELEASE.md (#566)

RELEASE.md

@@ -0,0 +1,38 @@
+# How to Release Packages
+This document covers how to do an official release of SlnGen.
+
+## Update Version
+SlnGen uses [semantic versioning](https://semver.org/) in the format major.minor.build to convey to users the kind of changes that were deployed:
+* Major - The release contains breaking changes from the last release
+* Minor - The release contains new features or functionality that did not exist before
+* Build - The release contains bug fixes or updates to dependencies that have no affect on the behavior of the tool
+
+For each release, decide on the impact of the changes. If it only contains bug fixes or dependency updates, you do not have to update anything.  If it contains new features or breaking changes, you should update the version
+ in [version.json](https://github.com/microsoft/slngen/blob/main/version.json) accordingly before creating a release.
+
+## Create GitHub release
+
+Releases are tagged with the same version as what is built.  However, you must determine ahead of time which version will be used.  To do this, build the repository from the main branch and note which version was used or look
+ at the most recent [Official Build](https://dev.azure.com/devdiv/DevDiv/_build?definitionId=12516&_a=summary).
+
+```
+D:\SlnGen>msbuild
+MSBuild version 17.9.0-preview-23557-02+5d1509792 for .NET Framework
+...
+
+  Successfully created package 'D:\SlnGen\src\Microsoft.VisualStudio.SlnGen\bin\Debug\Microsoft.VisualStudio.SlnGen.11.1.17.nupkg'.
+
+...
+```
+
+In this example, the version for the release is **11.1.17**.
+
+Create a new release at https://github.com/microsoft/slngen/releases.  The tag must be in the format of vMAJOR.MINOR.BUILD (The tag must start with a lead **v**). Using the above example, the tag would be `v11.1.17`.  Release notes
+ should contain the important commits that are relevant to that release and can be auto-generated by GitHub.  You can leave out commits that are not customer facing.
+
+Packages published to nuget.org use an Azure DevOps Service Connection [1ES-NuGet-Full](https://dev.azure.com/devdiv/DevDiv/_settings/adminservices?resourceId=841455b3-9379-4c8a-89a3-ec3ba7747d31).  The API key is good for one year
+ and will need to be regenerated when it expires.  If a release fails, you will need to update the service connection with a new API key and re-run the deploy stage.
+
+Packages published to the internal Azure DevOps Artifacts Services feed, specifically the CoreXT packages, use an Azure DevOps Service Connection [CloudBuild-Push](https://dev.azure.com/devdiv/DevDiv/_settings/adminservices?resourceId=da914f0a-3a04-4d03-b5dd-b54c2b715c00).
+  If a push fails, you will need to regenerate a Personal Access Token with permissions to push to the [CloudBuild](https://dev.azure.com/cloudbuild/CloudBuild/_packaging?_a=feed&feed=CloudBuild) feed and update the PAT in the
+  service connection.