The ggml-org team at Hugging Face tagged v1.0.0 of both llama.cpp and ggml on 13 November. The code that runs your GGUF models is not suddenly different. The point is a contract: “both llama.cpp and ggml will reflect API and ABI incompatibilities with major-version bumps.”
What v1.0.0 covers
The version applies to the libraries and their public headers:
- llama.cpp v1.0.0 is
libllama, with its public headers inllama.cpp/include/. - ggml v1.0.0 is
libggml, the tensor library underneath, with headers inggml/include/.
The rules are plain semantic versioning. A breaking change to the public C API in ./include bumps MAJOR. A backward-compatible feature, backend update, new model support or API addition bumps MINOR. A bug fix with no API change bumps PATCH. The team says the change is about “responsibility to those developers” who depend on the library, and that it will be “stricter about making those boundaries visible to downstream consumers.”
The numbered build tags do not go away. On GitHub, v1.0.0 is a full release published 13 November, while the frequent b12xxx builds that followed it are marked as pre-releases. The blog lists those pre-release artifacts plus Docker, Debian, Homebrew, conda-forge, MacPorts, Winget and an XCFramework for iOS and macOS as distribution channels.
What else the post says
The team says llama.cpp supports more than 150 architecture variants and the mainstream speculative decoding methods, and that ggml backends can be built as dynamic libraries and loaded at runtime. It credits hardware from NVIDIA, AMD, Qualcomm, Arm, IBM and Intel for self-hosted CI runners, and says it brings LLMs into its development process carefully while keeping control of the architecture.
If GGUF is new to you, our guide to what a GGUF file says before you load it and our plain explainer on quantization are good starting points. For a different take on local inference, see the Rust engine Kinetic.
Why this matters
The team says many downstream applications already depend on its libraries, and until now no version number told them when an update broke the API. With semantic versioning, you can pin to a major version, take minor and patch updates, and treat a major bump as a signal to read the changelog. Packagers also get a stable number to ship instead of a build count, which should make distro and Homebrew packages easier to keep current.

The Campfire
CommentsThanks. Your comment is waiting for the desk. Once it is approved it appears here within about a minute.
Add a comment