6  Release model

Kailash versions by release train and lock — the lockfile is the version of the system, and releases are named YYYY.NN (the versioning record):

• YYYY.NN release index — 2026.01, 2026.02 — where NN counts releases within the year, not the calendar month. A train may GA after the calendar page turns (2026.02 may GA in January 2027) and keeps its name.
• Staged ladder — 2026.01-alpha.1 → -rc.1 → bare 2026.01 (GA). Bare numbers are reserved for GA so a pre-GA cut is honest at tag-verification time; a material re-cut of a GA in its release month is 2026.01.1.
• Cut discipline — every cut runs a standing checklist: lane residue swept off the train’s target (leftovers re-scoped with a one-line reason, never silence), both repositories eval-clean across systems, manifest validation with the census snapshot in sync, VM/VM acceptance evidence recorded, a lock-bump release PR whose body is the release review, and a reference-hygiene pass over everything about to go public. The lock-bump PR lands before the signed tag; tag verification runs a real cache pull and the validator output goes into the release notes.

6.1 Update automation behind a release

Between releases, machine-driven checks work their cadences (weekly for fast-moving tool classes, monthly for the nixpkgs refresh) but every outcome is a reviewed pull request — dependency automation proposes, a human approves, smoke gates decide what is even proposed. Nothing updates a user’s system unprompted: an install moves forward when its operator rebuilds against a newer lock or adopts a release.