Release Process

1. Before making a new release, make sure that the version in Directory.Build.props is up to date.
2. Head over to the CHANGELOG file. Replace ## Unreleased with the new version name and add an additional ## Unreleased for future changes. Open and merge the PR for these changelog updates.
3. Then, draft a new GitHub Release with a list of changes contained in the new version from the CHANGELOG.
4. When the draft release is ready, publish it from the GitHub web UI. You can either have GitHub create a new tag for you from the GitHub Release page or push the tag yourself beforehand. Be aware, clicking Publish will trigger GitHub to push a new tag (as specified in the new Release entry, if not created by you already) which will instruct the CI to build and push a new stable release to NuGet.org.
5. If everything went well, congrats, the new versions should be live on NuGet by now. As a final post-release step, bump the minor version in Directory.Build.props to the next unreleased version number, so that nightly build versioning can benefit.

Updating Documentation

Please ensure that you review and update the documentation when making a new release. More specifically:

1. In README.md
   • Consul API version.
   • .NET Framework and .NET Core supported versions.
2. In docusaurus.config.js
   • .NET Framework and .NET Core supported versions.

Versioning

The version number indicates which version of Consul is supported in terms of API features. Since Consul already has a version that consists of three numbers (e.g. 1.6.1), the fourth number is necessary to indicate patch releases of Consul.NET.

Please note that NuGet normalizes version numbers, by omitting zero in the fourth part of the version number. For example version 1.6.1.0 is going to be normalized to 1.6.1. So to avoid problems, versions and tags with zero in the fourth part should be avoided and explicit three part version should be used instead.