Skip to main content

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. If the release includes public API changes, update the PublicAPI files:
    • Move all relevant entries from PublicAPI.Unshipped.txt to PublicAPI.Shipped.txt.
    • Ensure that PublicAPI.Unshipped.txt is empty (or only contains changes intended for a future release).
    • Open and merge a PR that contains these PublicAPI updates (this can be done together with the changelog PR).
  4. Then, draft a new GitHub Release with a list of changes contained in the new version from the CHANGELOG.
  5. 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.
  6. 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 semantic version, 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
    • .NET Framework and .NET Core supported versions.
  2. In docusaurus.config.js
    • .NET Framework and .NET Core supported versions.

Versioning​

Consul.NET follows semantic versioning using the format:

MAJOR.MINOR.PATCH

Historically, the project used four-component version numbers (e.g. 1.7.14.3) where the first three components matched a Consul server version. Starting with version 1.8.0, the project switched to standard three-component semantic versioning. Consul's HTTP API is largely backward compatible, so Consul.NET is not tied to a specific Consul server version.

Version increments follow the standard semantic versioning rules:

  • MAJOR version for breaking changes
  • MINOR version for new features
  • PATCH version for bug fixes