ggml-org released version 1.0.0 of llama.cpp and ggml on November 13, 2026, pairing the library releases with a commitment to mark API and ABI incompatibilities through major-version changes. For university research software maintainers, the milestone makes compatibility boundaries more explicit while introducing changes that existing integrations need to assess.
Version numbers now signal public interface changes
The team announcement identifies libllama as the C/C++ inference library and libggml as the machine-learning tensor library. It sets out three version-change rules for ggml-org projects using semantic versioning:
- A major increment marks an incompatible change in the public C interface defined by the include directory.
- A minor increment covers compatible additions, including features, hardware backends and model support.
- A patch increment covers fixes that leave the API unchanged.
For teams maintaining open source software, this gives dependency reviews a clearer signal for identifying releases that may require integration changes.
The 1.0 release removes deprecated interfaces
The llama.cpp release notes document removals from the public interface, including llama_set_warmup and deprecated functions. They also move the NextN speculative-decoding interface into llama.h and rename llama_set_embd_state_src to llama_set_ctx_state_src.
These changes give research teams concrete items to examine during research software code review. An integration that calls a removed or renamed function needs attention before the library upgrade can be treated as routine maintenance.
The accompanying ggml release also removes deprecated interfaces and legacy diagonal-mask operations. Its notes specify RPC protocol version 9 and rejection of incompatible peers. For a research deployment using RPC, that makes the peer protocol another compatibility boundary to examine alongside application code.
Release tags and nightly builds remain distinct
The maintainers’ release-process documentation distinguishes llama.cpp nightly tags, which begin with b, from official releases using semantic version tags. It says official release tags are created when the bundled ggml matches a released ggml version, supporting downstream builds that link against a system-installed library.
The llama.cpp 1.0.0 release page points to nightly build b12359 for assets. The announcement also outlines distribution channels, including package managers and platform frameworks, while describing expansion of distribution. That table should therefore be read as channel information and plans; it does not establish that a 1.0.0 package is already available through every listed route.
What changes for university research computing
The practical implication for university computing teams is a more explicit basis for separating a release upgrade from movement along the nightly development stream. A project’s dependency record can identify the actual tag and how ggml is supplied, giving future maintainers a more precise starting point for computational reproducibility.
For research offices supporting shared software, the immediate question is which maintained projects depend on the affected interfaces or RPC deployments. The release notes provide a focused basis for that assessment. The version policy communicates interface compatibility; a research team still needs its own evidence that an upgraded environment reproduces the results its project requires.
Sources
- ggml-org: llama.cpp v1.0.0 announcement, published 2026-11-13; checked 2026-11-14.
- ggml-org: llama.cpp v1.0.0 release notes, released 2026-11-13; checked 2026-11-14.
- ggml-org: ggml v1.0.0 release notes, released 2026-11-13; checked 2026-11-14.
- ggml-org: releases and versioning documentation; checked 2026-11-14.
