|
| 1 | +# llama.cpp version-bump runbook |
| 2 | + |
| 3 | +This is the **documentation root** for bumping the pinned llama.cpp version. It links the |
| 4 | +mechanical edit steps in [`../../CLAUDE.md`](../../CLAUDE.md#upgradingdowngrading-llamacpp-version) |
| 5 | +together with a repeatable **target-selection + chunking** strategy so a bump never lands an |
| 6 | +unreviewably large diff in one step. |
| 7 | + |
| 8 | +The current pin lives in `llama/CMakeLists.txt` as `GIT_TAG b<nnnn>`. llama.cpp tags **every** |
| 9 | +master commit as `b<nnnn>`, but only a subset get GitHub *Releases*. |
| 10 | + |
| 11 | +--- |
| 12 | + |
| 13 | +## TL;DR |
| 14 | + |
| 15 | +```bash |
| 16 | +# From the repo root. Prints the next reviewable step (b<cur> -> b<next>) and its compare/.patch URLs. |
| 17 | +.github/scripts/llama-next-version.sh # target = latest RELEASE (atom feed) |
| 18 | +.github/scripts/llama-next-version.sh b9900 # target = an explicit tag |
| 19 | +``` |
| 20 | + |
| 21 | +Then apply the printed `b<cur> -> b<next>` step per [§ Applying a bump](#applying-a-bump) and re-run |
| 22 | +the script to walk the next chunk, until it prints **"reaches the latest release — final chunk"**. |
| 23 | + |
| 24 | +--- |
| 25 | + |
| 26 | +## 1. Pick the target (topmost release) |
| 27 | + |
| 28 | +The **target candidate is the topmost release** on |
| 29 | +<https://github.com/ggml-org/llama.cpp/releases>. Read it from the release **atom feed**, which is |
| 30 | +reachable from restricted sandboxes where the ggml-org REST API is blocked: |
| 31 | + |
| 32 | +``` |
| 33 | +https://github.com/ggml-org/llama.cpp/releases.atom |
| 34 | +``` |
| 35 | + |
| 36 | +The first `<entry>`'s `releases/tag/b<nnnn>` is the latest release. `llama-next-version.sh` does this |
| 37 | +for you; if the feed is rate-limited (repeated unauthenticated fetches can return empty), open the |
| 38 | +releases page in a browser and pass the tag explicitly: `llama-next-version.sh b<nnnn>`. |
| 39 | + |
| 40 | +> **Why releases, not just the newest `b<nnnn>` tag:** releases are the versions upstream deems |
| 41 | +> shippable; an arbitrary master commit tag may be mid-refactor. Intermediate **chunk** steps |
| 42 | +> (below) are allowed to land on non-release tags — they are transient waypoints, not the target. |
| 43 | +
|
| 44 | +## 2. Chunk by diff **byte-size**, not commit count |
| 45 | + |
| 46 | +The step size is governed by the **size of `git diff` between the pinned tag and the target**, not by |
| 47 | +how many commits separate them: |
| 48 | + |
| 49 | +- If `git diff b<cur> b<target>` is **< 100 KiB**, bump straight to the target in one step. |
| 50 | +- If it is **≥ 100 KiB**, pick an **intermediate** `b<nnnn>` tag whose diff from the current pin is the |
| 51 | + largest still **under** the threshold, bump to that first, then repeat. Each step stays a small, |
| 52 | + reviewable patch. |
| 53 | + |
| 54 | +The threshold is a knob (`LLAMA_BUMP_MAX_DIFF_KB`, default `100`). This is a heuristic: diff size grows |
| 55 | +monotonically enough with the tag number that the helper binary-searches the intermediate tags safely. |
| 56 | + |
| 57 | +> **`tools/ui` (the WebUI) dominates the full diff** and is *auto-followed* — CI rebuilds the matching |
| 58 | +> Svelte UI from the pinned `GIT_TAG`, so it needs no per-bump source review. To size the diff on the |
| 59 | +> code you actually review, set `LLAMA_BUMP_EXCLUDE_WEBUI=1` (the helper prints both figures regardless). |
| 60 | +
|
| 61 | +### The helper: `.github/scripts/llama-next-version.sh` |
| 62 | + |
| 63 | +It only **reads** — a cached blobless mirror clone of llama.cpp plus `llama/CMakeLists.txt`; it never |
| 64 | +edits the repo. It prints the chosen `b<cur> -> b<next>` step, its full and WebUI-excluded diff size, |
| 65 | +the commit count, and the `compare` / `.patch` URLs. Environment: |
| 66 | + |
| 67 | +| Var | Default | Meaning | |
| 68 | +|---|---|---| |
| 69 | +| `LLAMA_BUMP_MAX_DIFF_KB` | `100` | Per-step diff-size threshold, in KiB. | |
| 70 | +| `LLAMA_BUMP_EXCLUDE_WEBUI` | `0` | `1` = size the diff **excluding** `tools/ui`. | |
| 71 | +| `LLAMA_BUMP_CACHE` | `~/.cache/jllama-llamacpp-mirror` | Mirror-clone location (cloned once, then fetched). | |
| 72 | + |
| 73 | +Worked example — pin `b9859`, latest release `b9866` (full diff 133 KiB ≥ 100 KiB, so it chunks): |
| 74 | + |
| 75 | +``` |
| 76 | +$ .github/scripts/llama-next-version.sh b9866 |
| 77 | +current pin : b9859 |
| 78 | +latest release : b9866 |
| 79 | +threshold : 100 KiB per step (full diff) |
| 80 | +
|
| 81 | +next step : b9859 -> b9862 |
| 82 | + diff size : 45 KiB full / ... KiB excluding tools/ui (auto-followed WebUI) |
| 83 | + commits : 3 |
| 84 | + progress : intermediate chunk — re-run this script after the bump for the next one |
| 85 | + review diff : https://github.com/ggml-org/llama.cpp/compare/b9859...b9862 |
| 86 | + raw .patch : https://github.com/ggml-org/llama.cpp/compare/b9859...b9862.patch |
| 87 | +``` |
| 88 | + |
| 89 | +## 3. Review the chunk's diff |
| 90 | + |
| 91 | +Fetch the printed `compare/...patch` URL (or open the `compare` page). Walk it against the |
| 92 | +**priority-ordered API-compatibility review list** in |
| 93 | +[`../../CLAUDE.md`](../../CLAUDE.md#files-to-check-for-api-compatibility) — the 8 header rows that have |
| 94 | +historically caused breaks (`common.h`, `chat.h`, `speculative.h`, `mtmd.h`, `llama-cpp.h`, `arg.h`, |
| 95 | +`llama.h`, `download.h`), plus the project `CMakeLists.txt` for renamed link targets. Note any new |
| 96 | +API surface worth wiring through the Java layer (e.g. a new completion param or model-metadata getter). |
| 97 | + |
| 98 | +--- |
| 99 | + |
| 100 | +## Applying a bump |
| 101 | + |
| 102 | +Once you have the `b<cur> -> b<next>` step, apply it exactly as |
| 103 | +[`CLAUDE.md § Upgrading/Downgrading`](../../CLAUDE.md#upgradingdowngrading-llamacpp-version) describes. |
| 104 | +Concretely: |
| 105 | + |
| 106 | +1. **Edit the pin — three files:** |
| 107 | + - `llama/CMakeLists.txt` — the `GIT_TAG b<cur>` line **and** the `-DLLAMA_TAG=b<cur>` used by the |
| 108 | + WebUI/TTS extraction (both must move together). |
| 109 | + - `README.md` — the llama.cpp badge and link (version appears twice). |
| 110 | + - `CLAUDE.md` — the "Current llama.cpp pinned version" line (and any build-example `b<nnnn>`). |
| 111 | +2. **Re-verify `patches/`** — a clean configure re-runs the fail-loud `PATCH_COMMAND`, so every patch |
| 112 | + `0001`–`0006` must still apply. Use a **fresh** build dir (a stale one re-applies over an |
| 113 | + already-patched tree and reports a false "does not apply"): |
| 114 | + ```bash |
| 115 | + cd llama && mvn -q compile # generates the OSInfo class CMake's OS-detection needs |
| 116 | + rm -rf build && cmake -B build # fail-loud: aborts here if any patch no longer applies |
| 117 | + ``` |
| 118 | + If a patch no longer applies, refresh its diff against the new source and recommit it. |
| 119 | +3. **Append the history rows** — add a pair of rows to |
| 120 | + [`../history/llama-cpp-breaking-changes.md`](../history/llama-cpp-breaking-changes.md) covering the |
| 121 | + `b<cur> -> b<next>` range (what broke / what was new; "no source change" is a valid row). |
| 122 | +4. **Commit + push** on the working branch (do not open a new PR if one already tracks the branch): |
| 123 | + ```bash |
| 124 | + git add llama/CMakeLists.txt README.md CLAUDE.md docs/history/llama-cpp-breaking-changes.md |
| 125 | + git commit -m "Upgrade llama.cpp from b<cur> to b<next>" |
| 126 | + git push -u origin <your-branch> |
| 127 | + ``` |
| 128 | +5. **Re-run the helper** for the next chunk. Repeat until it reports the **final chunk** (target |
| 129 | + reached). |
| 130 | + |
| 131 | +CI builds every native classifier from the new pin; the full model-backed Java + C++ suites gate the |
| 132 | +result. A build failure at the configure step almost always means a patch needs refreshing (step 2). |
0 commit comments