Vary uses Monotonic Channel Versioning (MCV) instead of Semantic Versioning. Every release has a single incrementing build number and a stability track.
v<build>-<track>[.<patch>]
The build number is a plain integer that increments with every release, regardless of track. The track tells you how stable the release is. An optional patch number (.1, .2, ...) allows hotfixes within a build.
Examples: v82-alpha.1, v90-beta, v100-rc, v105-stable
There are five tracks, ordered from least to most stable: dev, alpha, beta, rc, and stable.
dev builds are automated from main and may break at any time. These are for compiler contributors. alpha builds are feature-complete snapshots, tested but with rough edges, aimed at early adopters. beta is API-stable within the release and documents any breaking changes, intended for project authors tracking progress. rc (release candidate) means all RC gates pass and no further changes are planned, suitable for production evaluation. stable is fully validated and recommended for general use.
Build numbers only go up. v83 is always newer than v82, regardless of track. A higher build on a less stable track is still newer: v90-dev is newer than v85-stable.
Patch numbers reset per build. v82-alpha.1 and v83-alpha are unrelated; the .1 does not carry over.
Track promotion keeps the build number. If v90-beta is promoted, it becomes v90-rc, then v90-stable, same build, different track.
Two files in the repo root control the version. VERSION contains the build number as an integer (e.g. 82). RELEASE_SUFFIX contains the track with a leading dash, plus an optional patch (e.g. -alpha.1).
The full version string is v${VERSION}${RELEASE_SUFFIX}. The make release command increments VERSION and resets RELEASE_SUFFIX.
$ vary --version
Vary v82-alpha.1