feat(version): derive a git-based build version for dev builds

[rgao-coreweave]

Problem

Releases bump the version, tag vX, and push in one shot, so main always carries the last released version. A dev build off main reports the same string as the published release (e.g. 0.2.9) even when it has unreleased commits, so there's no way to tell "released 0.2.9" from "0.2.9 plus N dev commits" in the CLI or in Weave.

Approach

Industry standard for distinguishing dev builds without manual bookkeeping: derive the version from git describe. We attach it as semver build metadata (the +… part), which semver §10 defines as ignored for precedence — exactly right for "same release, plus dev provenance". The clean released string is left untouched.

• New BUILD_VERSION export. Defaults to VERSION; the build (scripts/build/copy-version-module.mjs) overwrites it in dist/version.mjs from git describe.
  • Exact clean tag → 0.2.9
  • Ahead of tag → 0.2.9+8.gabc1234
  • Dirty tree → …​.dirty
  • No git (published npm tarball) → falls back to 0.2.9
• BUILD_VERSION flows into the build-identity surfaces: CLI --version/help banner, status version, daemon service.version, the tracer, and the gen_ai.agent.version / weave.claude_code.plugin.version span attributes.
• Clean VERSION is kept where it must match the release tag: MARKETPLACE_REF, install metadata (settings.version), and weave.integration.version.
• Release automation (renderVersionModule) now emits BUILD_VERSION too, so version bumps don't drop the export.

Verification

git describe:        v0.2.9-4-g8a03d50-dirty
built CLI --version: 0.2.9+4.g8a03d50.dirty
source VERSION:      0.2.9

New unit tests cover the git describe → build-metadata mapping (clean tag, ahead, dirty, pre-release base, bare sha, fallbacks) and the no-git fallback. npm run check passes (76 tests).

Notes / decisions

• Build metadata (+) vs pre-release (-): went with build metadata so dev builds don't sort below the release they're built on. Appending a pre-release to the current version (e.g. 0.2.9-rc.0) would sort lower than 0.2.9, making a dev build look older than its base. If you'd rather adopt the "open the next dev version" model (0.3.0-dev.0 after each release), that's a small change to the release workflow instead — happy to switch.
• npm run dev (tsx from source, no build step) still reports the clean VERSION; only built/installed artifacts get the derived suffix. That's the realistic dev-build path (--source=local builds first).

🤖 Generated with Claude Code

[w-b-hivemind]

HiveMind Sessions

4 sessions · 17m · $4.63

Session	Agent	Duration	Tokens	Cost	Lines
Daemon Restart Skill For Weave Claude f6be43fa-bf74-49da-b5e9-09cef12debd5	claude	2m	17.5K	$0.66	+1 -1
Hello World Program c035782d-9c60-4356-85f6-1e138bea1943	claude	2m	19.0K	$0.76	+0 -0
Weave Claude Code Plugin Installation 5c882a51-99b3-4b5b-8484-4fe3d8a00471	claude	1m	10.2K	$0.40	+0 -0
Version Bumping Release Candidate Strategy d23bf1ec-1f57-4077-b1aa-47d6c7a4dbdb	claude	11m	56.9K	$2.82	+201 -21
Total		17m	103.6K	$4.63	+202 -22

View all sessions in HiveMind →

Run claude --resume f6be43fa-bf74-49da-b5e9-09cef12debd5 to pickup where you left off.