GitVersion.yml

# yaml-language-server: $schema=https://raw.githubusercontent.com/GitTools/GitVersion/main/schemas/6.0/GitVersion.configuration.json
#
# GitVersion answers "what version is *this* commit?" for builds that are not releases: CI
# artifacts and pull-request builds get a real, ordered SemVer instead of 0.0.0. It never decides
# what the next release is — semantic-release does that from the conventional commits and writes
# the `vX.Y.Z` tag, which GitVersion then reads back.
#
# It runs once per pipeline run (the `version` job in .github/workflows/ci.yml), not as an MSBuild
# task, and that job is allowed to fail: see the Versioning block in Directory.Build.props for why.
# Locally: `dotnet tool restore && dotnet gitversion`.
#
# Trunk-based: `main` is the only long-lived branch (see CONTRIBUTING.md), so the GitHubFlow
# preset fits; anything not matched below falls through to its catch-all branch configuration.
workflow: GitHubFlow/v1

mode: ContinuousDelivery
tag-prefix: '[vV]?'

# Where versioning starts while no `vX.Y.Z` tag exists. The first tag outranks this, after which
# the line is inert. It is not a way to steer releases — semantic-release decides those.
#
# Note that this does not rescue every git shape: GitVersion treats a branch with no merge base
# against a release branch as orphaned and refuses to version it at all, `next-version`
# notwithstanding. That is why the pipeline tolerates GitVersion failing rather than relying on
# configuration to make it impossible.
next-version: 0.1.0

# AssemblyVersion stays at major.minor.patch so a patch release does not force a binding redirect
# on .NET Framework consumers. The exact build lands in FileVersion / InformationalVersion, which
# is where a diagnostic tool looks anyway.
assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatch

branches:
  main:
    label: ''
    increment: Patch
  pull-request:
    label: pr