[Bug]: C API reports version 0.2.1 when git tags are missing (shallow clones)
envgap__alibaba__zvec-621
01 / FAILURE SIGNATURE
As reported upstream
No identifying execution failure has been captured.
Not a benchmark task.
- In a clean container the reported failure did not reproduce, or the known fix did not make the project run.
02 / ENVIRONMENT RECIPE
- Base commit
82eb4374eb4260d2662b64d07be659843e0c5b1b- Manifest
CMakeLists.txt- Reproduce
Awaiting issue-specific recipe- Run under trace
Awaiting a meaningful runtime command
03 / ORIGINAL ISSUE TEXT
alibaba/zvec #621 · read the original issue
### Description
In `src/binding/c/CMakeLists.txt`, if `git_version` / `ZVEC_VERSION` doesn't match `vX.Y.Z`, the CMake falls back to **0.2.1** and that string gets baked into the generated C API version headers.
On a current **0.5.x** tree that's wrong. Shallow CI checkouts (and any clone without tags) often get `g<sha>`-style describes, hit the fallback, and advertise **0.2.1** even though you just built tip-of-tree.
### Why it matters (more than a cosmetic wrong string)
Anything that trusts the native version / ABI from the C API will behave badly:
1. **ABI / compatibility gates** — consumers that require "≥ 0.5.x, same major" reject a binary that claims 0.2.1 even though the code is current. We hit this packaging zvec's C API in CI: natives built, then failed ABI checks until we patched the fallback locally.
2. **Shallow submodules / Docker / `fetch-depth: 1`** — common in GitHub Actions; exactly the setup that skips tags.
3. **Any other binding** (Python/Node/C) that surfaces or asserts on that version can mis-report or fail CI the same way.
So this isn't "docs say 0.5.1 but I expected a prettier string" — it's a **lying ABI identity** under normal CI clone shapes.
### Steps to Reproduce
```bash
git clone --depth=1 --recurse-submodules https://github.com/alibaba/zvec.git
cd zvec
# ensure no tags visible, or use a describe that isn't vX.Y.Z
cmake -B build -G Ninja -DBUILD_C_BINDINGS=ON ...
# watch configure: fallback to 0.2.1 / generated zvec_version.h
```
Relevant snippet (current tree):
```cmake
else()
# Default version if parsing fails
set(ZVEC_VERSION_MAJOR 0)
set(ZVEC_VERSION_MINOR 2)
set(ZVEC_VERSION_PATCH 1)
...
endif()
```
File: `src/binding/c/CMakeLists.txt` (parse of `ZVEC_VERSION` after `git_version(...)`).
### Suggested fix
Drive the version from a checked-in `VERSION` / release file, or bump the fallback to the current release and keep it in sync — don't require a full tag history for a correct C API version string.
### Additional Context
Happy to test a PR. This bit us while packaging the C library for .NET (AdamSystems.ZVec.NET); same footgun for anyone else doing shallow builds.
### Operating System
Any (reproduced in Linux/macOS/Windows CI with shallow submodule checkouts).
### Build & Runtime Environment
- zvec ~0.5.1 tree with shallow clone / no tags in `git describe`
- `BUILD_C_BINDINGS=ON`
04 / LABELS
Labels from the report text only; not yet run
No supported category has been assigned.
Label rules and the text that matched
[]