← All tasks
cppalibaba/zvec #621Not a task: not reproduced

[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`

Continue on GitHub ↗

04 / LABELS

Labels from the report text only; not yet run

No supported category has been assigned.

Label rules and the text that matched
[]