Versioning, release cadence, etc.

[znmeb]

I'm just getting started with llama.cpp - building it from source on a machine with an RTX 3090. As a test I installed using the public method - curl -LsSf https://llama.app/install.sh | sh. That installed version b10217. The latest version is b10488 and that appears to be updated quite frequently.

So I updated the install via ~/.llama-app/llama update. It went through the downloading motions but once that was done, the version was still b10217-ddd4ec142.

I would like my source builds to use the same version a public user gets, just compiled locally for maximum machine optimization. So:

1. How do I determine the latest public release tag to check out?
2. How does the project determine which release is published to the install script?

[0xshubhs]

The two tag series are different things, which is the source of the confusion:

• bNNNN — nightlies, cut automatically per master commit by release.yml. Several a day (b10483, b10485, b10486, b10488 all landed on Aug 18). These are the ones carrying the binary assets, and releases/latest points at the newest one.
• v0.1.x — the new semver line. v0.1.2 is marked pre-release, has no assets, and its body pins the nightly it was cut from ("Nightly build: b10485"). Semver is explicitly still WIP — see dist : releases and versioning of `ggml-org` projects ggml#1579.

Answering your two questions:

1. Latest public tag to check out

gh release view --repo ggml-org/llama.cpp --json tagName -q .tagName   # newest nightly, b10488 today
git fetch --tags && git checkout b10488

For the semver line instead, use gh release list --repo ggml-org/llama.cpp and take the newest v0.1.x, then read its body for the matching bNNNN.

2. How the published release is chosen

make-release.yml is workflow_dispatch-only — a maintainer triggers it by hand, it runs scripts/make-release-checks.sh, then tags and creates the release. So the semver releases are cut manually; only the nightlies are automatic. That's why the installer stays put for long stretches while bNNNN keeps climbing.

Your llama update staying on b10217-ddd4ec142 is consistent with the installer tracking the release channel rather than nightlies — worth a separate issue if you think it should have moved.

[znmeb]

No, I don't think the installer should be moved - I want to update my code so it compiles the same version the installer downloads. So I'm going with 1. Thanks!!

[znmeb]

Looks like the recent pre-release is the only 'v' tagged release:

gh release list --limit 180 --repo ggml-org/llama.cpp | gzip -9 > llama.cpp-releases.gz

llama.cpp-releases.gz

I'll just run the installer manually for now and grab the 'b' number until pre-releasev0.1.2 makes it to a regular release.