MinVer: Git-tag-driven versioning for .NET projects

What problem MinVer solves for .NET versioning

MinVer is a minimalist .NET build package that versions .NET SDK-style projects using Git tags. It exists for teams who want the version number to come from repository history rather than from a manually edited project file. A companion tool, minver-cli, is a .NET tool for versioning any kind of software or content that is not built with a .NET SDK-style project. Both are developed by humans and target the same workflow: tag a commit with a SemVer 2.x version, build, and let the tool apply the number to assemblies and packages.

How MinVer derives a version from Git history

The rules are deterministic and branch-unaware. If the current commit has a version tag, that version is used as-is. If it does not, MinVer searches commit history for the latest commit with a version tag. When that tag is a pre-release, the version is used as-is with height added. When it is an RTM version, the patch number is incremented, default pre-release identifiers of alpha.0 are added, and height is added; the example in the README is that a latest tag of 1.0.0 produces 1.0.1-alpha.0. If no version tag exists at all, the default version 0.0.0-alpha.0 is used with height added.

Height is the number of commits since the latest commit with a version tag, or since the root commit when none exists; for example, a 1.0.0-beta.1 tag at a height of 42 commits yields 1.0.0-beta.1.42. Height can be disabled. Because MinVer is unaware of the branches containing a commit, it works with any branching or release strategy. The pre-release and patch-increment behaviour can be customised, and the default pre-release identifiers can be changed from alpha.0 to something else, according to the README.

Installing MinVer and tagging a release

Prerequisites are .NET SDK 8.0 or later and Git. The quick start is to install the MinVer package and build the project; the project is then versioned according to the latest tag in commit history.

git tag 1.2.3
git push --tags

The first command creates a tag whose name is a valid SemVer 2.x version, and the second publishes it. When you build from the tagged commit, MinVer applies the version to assemblies and packages. The README notes that the MinVer package reference should normally include PrivateAssets="All", and that an IDE or tool usually sets this automatically. For GitHub Actions, Azure Pipelines, and Travis CI, the fetch depth must be set appropriately so tags are available, otherwise the default version may be used even when a version tag exists in history.

The version numbers MinVer writes into a project

MinVer sets custom properties named MinVerVersion, MinVerMajor, MinVerMinor, MinVerPatch, MinVerPreRelease, and MinVerBuildMetadata. These feed the standard.NET SDK properties: AssemblyVersion becomes {MinVerMajor}.0.0.0, FileVersion becomes {MinVerMajor}.{MinVerMinor}.{MinVerPatch}.0, InformationalVersion becomes {MinVerVersion}, and PackageVersion and Version become {MinVerMajor}.{MinVerMinor}.{MinVerPatch} or the same with a pre-release suffix. This behaviour can be customised, and the properties can be used for other purposes beyond the standard.NET SDK properties.

Where MinVer is the wrong fit

MinVer depends on Git history being present in the build environment. Shallow clones that omit tags can silently fall back to the default 0.0.0-alpha.0 version, which is a real failure mode in CI. It is also branch-unaware, so it cannot distinguish release branches from feature branches; teams needing branch-specific versioning must look elsewhere. The main package targets.NET SDK-style projects, and non-.NET content needs minver-cli instead. The README does not document rollback behaviour or an upgrade path between major versions.

How it compares with editing version files by hand

Manual versioning edits a csproj or AssemblyInfo file and relies on every contributor remembering to bump it. MinVer moves the single source of truth to a Git tag on the release commit, which removes merge conflicts on version bumps and ties the number to an exact commit. The cost is discipline: every release needs a valid SemVer 2.x tag, and the build environment must fetch tags. A hand-edited file is simpler when the project has no Git history or when tags are not part of the release process. The trade-off is that the build now depends on Git state, which makes builds less reproducible outside a checkout.

Maintenance, runtime requirements, and licensing

The last push was on 2026-10-15, and the repository is not archived. Prerequisites remain .NET SDK 8.0 or later and Git, so the runtime cost is the SDK and a Git checkout rather than extra services. The project is licensed under Apache-2.0. The repository has no GitHub releases, so version history of MinVer itself is tracked through Git rather than release pages.

Editorial conclusion

Adopt MinVer if you build .NET SDK-style projects and want versions driven by Git tags; skip it if your build environment cannot provide full Git history or you need branch-aware versioning; verify first that CI fetch depth includes tags and that your tag names are valid SemVer 2.x.

Frequently asked questions

Official sources

1. adamralph/minver on GitHub
2. Issues
3. License: Apache-2.0
4. README