- Before making a new release, make sure that the version in Directory.Build.props is up to date.
- Head over to the
## Unreleasedwith the new version name and add an additional
## Unreleasedfor future changes. Open and merge the PR for these changelog updates.
- Then, draft a new GitHub Release with a list of changes contained in the new version from the CHANGELOG.
- 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.
- 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.propsto the next unreleased version number, so that nightly build versioning can benefit.
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
126.96.36.199 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.