News

llama.cpp and ggml reach v1.0.0, set rules for breaking changes

The ggml project released llama.cpp and ggml libraries at version 1.0.0, committing to major-version increases when future changes break API or ABI compatibility.

D
Nov 14, 2026 · 1 min read

The ggml project released llama.cpp and ggml libraries at version 1.0.0 on November 13, pairing the milestone with a commitment to increase their major version when future changes break API or ABI compatibility.

For developers who depend on the libraries, the policy turns the version number into an explicit signal for incompatible interface changes. Under the project’s rules, a major increase marks a breaking change to the public C API. A minor increase covers a backward-compatible feature, backend update, model-support change or API addition. A patch increase covers a bug fix with no API change. Those categories follow the Semantic Versioning 2.0.0 specification.

The commitment covers libllama’s public headers in llama.cpp/include/ and libggml’s public headers in ggml/include/. The announcement says future ABI incompatibilities will also require a major-version increase.

Version 1.0.0 includes breaking cleanup. The llama.cpp release removes deprecated public API, including 35 deprecated functions. The ggml release prunes deprecated public API and removes legacy DIAG_MASK operations.

Both releases add features alongside the compatibility changes. llama.cpp adds OCP FP8 key-value caches, a host-memory mixture-of-experts cache with a configurable CPU share, external PLE shard loading, additional model architectures, server hardening and a speech endpoint. ggml adds configurable YaRN truncation and FP8 support, with performance work across CUDA, Metal, Vulkan, SYCL, OpenCL, WebGPU and Hexagon backends.

In a release-preparation discussion, ggerganov said major releases would likely occur more often than the interval between the pre-1.0 line and v1.0.0 because incompatible API or ABI changes will now be versioned more strictly. The published material does not define a separate ABI-compatibility test. It also does not promise a deprecation window, long-term-support branch or migration period before a future major release.

More news