Skip to content

RELEASING.md

Latest commit

 

History

History
73 lines (60 loc) · 3.28 KB

RELEASING.md

File metadata and controls

73 lines (60 loc) · 3.28 KB
Raw

Releasing langid.cpp

There is no release pipeline. No tags, no CI publish workflow, no registries, no prebuilt artifacts. This file records where the version lives and what a first release would have to add.

The version

The single source of truth is include/langid.h:

#define LANGID_VERSION_MAJOR 0
#define LANGID_VERSION_MINOR 1
#define LANGID_VERSION_PATCH 0

The top-level CMakeLists.txt parses those three macros before project() to set the CMake project version and the shared-library VERSION / SOVERSION, and langid_version() returns the same string. Nothing else declares a version, so a bump is a one-line edit and a reconfigure. Pre-1.0 the SOVERSION is MAJOR.MINOR, encoding the policy that the ABI may break on a minor.

langid_version_commit() reports the short git SHA captured at configure time (unknown outside a git tree). It is a snapshot: reconfigure to refresh it.

What a release would need

Condensed from transcribe.cpp's RELEASING.md, which is the model to follow when the time comes.

  • A remote. Nothing has ever been pushed.
  • An ABI digest. transcribe.cpp installs a transcribe.abihash alongside the header and validates it before dlopen. langid.cpp has no equivalent; the install rules leave a marked hole for it (cmake/langid-install.cmake).
  • A version-consistency check. transcribe.cpp's scripts/release/prepare.py writes the version into ~15 files and --check verifies the tree. langid.cpp declares it in exactly one place today, so this is only needed once there are binding manifests (Cargo.toml, package.json, pyproject.toml, lockfiles) to keep in step.
  • Published GGUFs. The model is Apache-2.0 and convertible from the pinned upstream revision, but no converted file is hosted anywhere. A release needs a home for them and the sha256 manifest already in docs/model.md.
  • A publish.yml triggered by a v[0-9]* tag, building per-platform artifacts. The tag run must not be the gate: branch CI on main is, because a tag run does not re-run the drift checks.
  • Real-model CI. LANGID_BUILD_REAL_MODEL_TESTS and the validation gates need a GGUF that CI can fetch. Today they are local-only.
  • A CHANGELOG.
  • Names claimed on whatever registries the bindings target (langid-cpp / @langid-cpp/<tuple> were unclaimed as of PLAN-v1).

The release checklist, once that exists

  1. Branch, bump include/langid.h, reconfigure, commit.
  2. Green branch CI on the PR: native-ci (cpp-tests on Linux and macOS, cpp-tests-sanitized, shared-build with the install + link smoke) and clang-format.
  3. Locally, against the F32 GGUF: uv run scripts/validate.py all --family ecapa_tdnn and the dataset gate (scripts/eval/compare.py, see docs/validation.md). Neither runs in CI.
  4. Merge, then tag the merged commit on main and push the tag. The tag string must equal the version in the header.
  5. Update docs/accuracy.md and docs/latency.md if any measurement moved.

The ggml pin is not yours to move

A langid.cpp release never bumps ggml on its own. ggml moves when transcribe.cpp moves, and a langid release names the transcribe.cpp tag whose ggml it mirrors. See docs/distribution.md.