Current Version Current Version Release Build Static Badge

Git2SemVer

No limits .NET solution versioning.

Git2SemVer is a Visual Studio and developer friendly Semantic Versioning framework for .NET solution and project versioning. It works the same with both Visual Studio and dotnet CLI builds. Every build, on both developer boxes and the build system, get traceable build numbering (no commit counting).

This tool is best for suited teams that:

  • Wants true Semantic Versioning.
  • Uses Conventional Commits to automatically generate change logs.
  • Uses branches to separate releasable code from feature or under development code (e.g: GitHub flow or GitFlow).
  • Only releases builds from a build system (or controlled host).
  • Wants to avoid custom build scripts, or tools, on a build system.
  • Uses Visual Studio as well as dotnet CLI.
  • Values full traceability for every build regardless if on a build system or an uncontrolled developer box (commit counts/depth will not do).
  • Needs unique versioning customisation that internal C# scripting may provide.

Features

Visual Studio Friendly
Semmantic Versioning
Conventional Commits

Versioning, with build numbering, on every Visual Studio or dotnet CLI build.

.NET developer friendly. Fast and silent

Benefit from comprehensive industry standard Semmantic Version compliance.

Only tool compliant with initial development versioning.

Use the same commit message standards for versioning that you also use for automated changelog generation.

#
Environment Parity
Build Numbering
C# Scripting

Visual Studio, VS Code, and dotnet CLI are all the same to Git2SemVer. Build system and developer environments all get versioning without custom build steps or scripts.

Automatic build numbering on all developer boxes and the build system builds.

Full traceability. Build height NOT used.

No limits customisable by built-in C# scripting with a versioning API.

Open Source
Build Host Adaptive Versioning
Git Workflow Agnostic

Free and open source.

The versioning adapts according to the build host.

e.g: Prelease/metadata identifiers are added to identify dev box builds.

No Git workflow configuration required. It works the same for GitFlow and GitHub Flow.

TeamCity Integration
GitHub Workflows

Automatic build system detection with server build number (label) updated with a build version specifically adapted for TeamCity.

Built in support for builds using GitHub Actions.

Constructs build number from run and run attempt numbers and adapts the version for GitHub builds.

Quick introduction

You identify a release by adding a git tag like "v1.2.3" to the release's commit. Then, Git2SemVer works out build version of following commits by identifying breaking changes, new features, or bug fixes from from your Conventional Commits compliant commit messages. You already use Conventional Commits generate your changelog so it is getting two for the price of one.

Versioning includes:

  • .NET file and assembly versions
  • NuGet package version (including version in filename)

The branch name determines if the build is a release build or a alpha/beta/rc pre-release build. See Build maturity identifier for more information.

For no limits customisation, Git2SemVer detects and executes an optional C# script that can change any part of the versioning.

It can be configured for any mix of solution versioning and individual project versioning without external build-time tools. No build system version generation steps are needed, keeps developer and build environments simple and aligned.

License

Git2SemVer uses the MIT license.

Acknowledgments

This project uses the following tools and libraries. Many thanks to those who created and manage them.

Edit this page