Vary uses Monotonic Channel Versioning (MCV) instead of Semantic Versioning. Every release has a single incrementing build number and a stability track.

## Format

```text
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`

## Tracks

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.

## Monotonicity rules

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.

## How it works in the repository

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`.

## CLI output

```text
$ vary --version
Vary v82-alpha.1
```