The v0.0.28 release binary identifies as `m-dev` instead of `0.0.28`

[rossmorey]

Agent Diagnostic

The investigation found the exact bug: git_version() in build.rs matches vm-dev tag, producing "m-dev" version string.

Bug

The v0.0.28 release binary identifies as m-dev:

$ openshell --version
openshell m-dev

Agent Diagnostic

Root cause: crates/openshell-core/build.rs:65-68

git describe --tags --long --match "v*" matches both v0.0.28 and vm-dev (both start with v). Since vm-dev is on a more recent commit, git picks it:

git describe --tags --long --match "v*"
→ vm-dev-1-g463f65a

Then line 76 strips the v prefix:

"vm-dev-1-g463f65a".strip_prefix('v') → "m-dev-1-g463f65a"

Parsing splits on hyphens from the right:

• tag = "m-dev", commits = 1, sha = "g463f65a"

splitn(3, '.') on "m-dev" fails (no dots), so git_version() returns None. The fallback CARGO_PKG_VERSION is 0.0.0.

However, the release pipeline's sed patch (.github/workflows/release-tag.yml:268) sets CARGO_PKG_VERSION to the release version. If the pipeline ran correctly, the binary should show 0.0.28. The m-dev output suggests OPENSHELL_GIT_VERSION was set explicitly somewhere, or the local copy of the source code being investigated differs from the release build environment.

Files:

• crates/openshell-core/build.rs lines 64-96 (git_version())
• crates/openshell-core/src/lib.rs lines 31-34 (VERSION const)

Suggested Fix

Change the --match pattern from v* to v[0-9]* so it only matches semver tags, not vm-dev:

.args(["describe", "--tags", "--long", "--match", "v[0-9]*"])

Expected:

openshell --version → openshell 0.0.28

The fix is one character change: "v*" → "v[0-9]*" in build.rs line 67.

Description

openshell --version reports m-dev on the v0.0.28 release binary (Linux ARM64). Expected: 0.0.28.

Reproduction Steps

1. Download the v0.0.28 Linux ARM64 binary from the GitHub release
2. Run openshell --version
3. Output: openshell m-dev (expected: openshell 0.0.28)

Environment

• OS: Ubuntu 24.04 LTS (aarch64), running inside Parallels VM on macOS (Apple Silicon)
• OpenShell: v0.0.28 release binary (Linux ARM64)

Agent-First Checklist

• I pointed my agent at the repo and had it investigate this issue
• I loaded relevant skills (e.g., debug-openshell-cluster, debug-inference, openshell-cli)
• My agent could not resolve this — the diagnostic above explains why

[mjamiv]

Reproduced on v0.0.29 as well (installed via uv tool install openshell==0.0.29 --force on x86_64 Linux, x86_64 manylinux wheel):

$ openshell --version
openshell m-dev

Same root cause as in the OP — vm-dev is on a more recent commit than v0.0.29 so git describe --tags --long --match "v*" resolves to it.

The minimal fix to crates/openshell-core/build.rs is to require a numeric segment after the leading v:

- "git describe --tags --long --match v* HEAD"
+ "git describe --tags --long --match v[0-9]* HEAD"

That excludes vm-dev, vm-prod, etc. without losing any release tag (all release tags follow v\d+\.\d+\.\d+).

Side note for anyone scripting against --version: the bug shipped in two consecutive releases now (v0.0.28 and v0.0.29), so version-probe scripts should not rely on this output until the fix lands.