cutver

The version is arithmetic. The prose is the work.

Works out the next version from your commit messages, writes it into every manifest, and stops.

bunx cutver stage --dry-run

That run is against a JavaScript repository with --offline, which is why it says preflight: skipped. Given a config that publishes, the preflight block asks the registry about every package before a single file is written — and a Cargo repository publishes nothing by default, so it skips for a different reason. Configuration covers what a tag produces.

It does not publish. Publishing is the one irreversible step in a release — a registry never lets a version number be reused, by anyone, ever — so it gets its own trigger, its own credentials, and something that decided to run it. This gets the tree to a releasable state and stops.

Install

Nothing to install for a repository that already has Bun:

bunx cutver stage --dry-run

For one that does not — a Rust workspace, a CI image without a package manager — every release attaches a standalone executable with no runtime:

curl -L -o cutver https://github.com/obillekyle/cutver/releases/latest/download/cutver-linux-x64 && chmod +x cutver

cutver-{linux,darwin}-{x64,arm64} and cutver-windows-x64.exe. Full options, including pinning a version, in Install.

Documentation

cutver.okyle.dev — the whole of it. Source in docs/, and the pages worth starting from:

| | | | --- | --- | | Your first release | Start here. What to run, in order, and why the first publish is manual. | | Set up CI | cutver init scaffolds the release setup. What each file does, which parts are yours to edit, and the two it changes rather than adds. | | Writing the commits | The only input cutver reads. The subject decides the version; the body becomes the release note. | | How the number is chosen | The ranges, the baseline, and what happens with no tags. | | Alphas, betas and RCs | Prereleases, and branches that declare their own version. | | Changelogs | Compiling the file, and handing the release body to a model. | | CLI | Every command and flag. | | Configuration | Every config key, and what omitting it means. | | Troubleshooting | When something has already gone wrong. |

Or ask it directly:

cutver help

cutver doctor

doctor is the one to reach for when a release is not doing what you expected: it reports the config as resolved, the plan for this branch, drift between your config and the generated workflows, and whether the registry has heard of each package.

Development

bun run test

bun run typecheck

bun run build

bun run build --all cross-compiles every release target.

Provenance

src/version-from-commits.ts and its tests were extracted verbatim from the bakery monorepo (the @bakery-framework/* packages), where the rules were worked out against a real release history — the comments cite that history, and they are kept because the evidence is what makes each rule worth trusting. The rest of this repository is the part that was coupled to npm, generalised behind the adapter interface.

License

MIT