Skip to content

Latest commit

 

History

History
38 lines (27 loc) · 2.79 KB

RELEASE.md

File metadata and controls

38 lines (27 loc) · 2.79 KB
Raw

How to Release Packages

This document covers how to do an official release of SlnGen.

Update Version

SlnGen uses semantic versioning 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 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.

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. 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. If a push fails, you will need to regenerate a Personal Access Token with permissions to push to the CloudBuild feed and update the PAT in the service connection.