zerv version is general-purpose version generation: it reads VCS state (or stdin), applies
overrides, and renders through a schema. Unlike
zerv flow, it generates versions as-is, with no opinionated
auto-bumping logic. It does not automatically increment post-counts based on commits or
tags, nor derive pre-release labels and numbers from branch patterns.
The pipeline
- Input - pick a source:
git(auto-detected VCS),stdin(piped ZERV RON), ornone(overrides only) - VCS detection - the latest reachable tag, its distance, the current branch and commit, and whether the working directory is dirty
- Parsing - tag version and overrides resolve into the version variables
- Transformation - optional bumps (
--bump-major, …) apply - Format output - the schema and format/template render the final string
Input sources
Source auto-detection: zerv auto-detects the input source (stdin if piped, git otherwise).zerv RON format: the internal representation of a fully-resolved
version. Generate it once with --output-format zerv, then re-render it into any number of
formats downstream. See formats and templates.
Overrides
Every value the pipeline detects can be overridden: VCS values (--tag-version,
--distance, --dirty, --bumped-branch, --bumped-commit-hash, --bumped-timestamp) and
version components (--major, --minor, --patch, --epoch, --post, --dev,
--pre-release-label, --pre-release-num).
Overrides make zerv reproducible in CI, where you often have a checked-out ref but want the
version pinned to event metadata:
Bumping
Two bump strategies:- Field-based -
--bump-major,--bump-minor,--bump-patch(stackable), plus--bump-post,--bump-dev,--bump-epoch,--bump-pre-release-* - Schema-based -
--bump-core <index>targets a component position in the current schema, so custom schemas bump correctly too
Where to go next
- Version CLI - every flag with tested examples
- Schema system - how the version string is assembled
- Config file - commit your repo’s policy once