ReleaseTools.ScalVer 1.20260906.10

Scalable Calendar Versioning (ScalVer)

Overview

ReleaseTools.ScalVer is a .NET tool that combines a manually controlled major version with a date and commit count. It prints the version to stdout, making it suitable for local scripts and release pipelines.

ScalVer combines Semantic and Calendar Versioning:

{MAJOR}.{DATE}.{PATCH}

• MAJOR — reserved for breaking changes, bumped manually via -m
• DATE — calendar component from the effective HEAD commit date in UTC (YYYY, YYYYMM or YYYYMMDD)
• PATCH — number of commits within the current date window (like CalVer)

Every ScalVer version is syntactically valid SemVer, so package managers and version comparison work unchanged:

1.2025.0 < 1.202502.0 < 1.20250223.0 < 2.2025.0

Installation

dotnet tool install --global ReleaseTools.ScalVer

The installed command is scalver. To upgrade an existing installation:

dotnet tool update --global ReleaseTools.ScalVer

Requirements

• The .NET 10 SDK
• Git available on PATH
• A Git repository with at least one commit
• Full Git history; shallow clones can undercount commits in the selected date window

In GitHub Actions, configure actions/checkout with fetch-depth: 0 so the full commit history is available.

Usage

scalver -m <MAJOR> [options]

Options

Date Formats and PATCH Windows

The DATE segment may lengthen over time within a MAJOR line (YYYY → YYYYMM → YYYYMMDD) but should never shrink — shrink requires a MAJOR bump. The tool does not enforce this; it's a convention you follow by choosing -m and -d deliberately.

Breaking Changes

There is no commit-message analysis: when you make a breaking change, bump -m yourself. The date window's commit count keeps PATCH meaningful without any tags.

Examples

# Monthly cadence, 3 commits this month
scalver -m 1
# 1.202502.3

# Daily cadence
scalver -m 1 -d YYYYMMDD
# 1.20250223.1

# Breaking change: you decide
scalver -m 2
# 2.202502.3

# Prerelease + build metadata
scalver -m 1 -p rc -b
# 1.202502.3-rc+a1b2c3d

When to Use ScalVer

• Projects needing time-based clarity (when was this released?)
• Projects needing SemVer compatibility (does this break my API?)
• Projects with varying release cadence (yearly → monthly → daily)
• Projects with both stable and rapidly-changing components