* cmake : introduce semantic versioning (wip)
This commit introduces semantic versioning to llama.cpp.
* squash! cmake : introduce semantic versioning (wip)
* cmake : update test-cmake README notes [no ci]
* include libmtmd in output so show its semversioned
* ci : add make-release workflow
* ci : fix build number check in build-cmake-pkg.yml
* examples : remove trailing whitespace
* ci : abort if upstream ggml version does not exist
* ci : extract step contents into scripts
* ci : add GGML_NATIVE=OFF to ubuntu job
* examples : remove CI build information from test-cmake [no ci]
This commit removes the nightly/release information that I added
previously to keep this focused only on using building and installing
llama.cpp with cmake and being able to quickly verify changes or
troubleshoot issues.
* ci : merge scripts into single script
* remove -dev-build_number support
This commit removes the incremental build number (versioning) support
that I added. This was incorrect and we should only use the semver for
the version. Releases will be tag a nightly build and package
maintainers/managers that build from source can use the tag and it is
therefor important that the correct version is reported. So a
nightly-build will report the semver without the build number. The build
number and commit as availble via cmake and test-cmake has been updated
to include an example of using them:
```console
$ ./build.sh
[test-cmake] version: 0.1.0, build: 10360 (08c69e381)
...
```
Refs: https://github.com/ggml-org/llama.cpp/pull/26839#discussion_r3755836969
* docs: add initial release.md documentation
* cmake : clean-up and add LLAMA_BUILD_IS_DEV option
* ci : remove version input from make-release job
* ci : add LLAMA_BUILD_IS_DEV=OFF to build-cmake-pkg.yml
Refs: https://github.com/danbev/llama.cpp/actions/runs/31576801921/job/94050639145
* docs : update release notes with LLAMA_BUILD_IS_DEV info [no ci]
* ci : add TODO to winget workflow [no ci]
---------
Co-authored-by: Georgi Gerganov <ggerganov@gmail.com>
1.9 KiB
Release process
llama.cpp uses semantic versioning (MAJOR.MINOR.PATCH).
Version bump guidelines
| Change type | Version component |
|---|---|
Breaking change to the public C API (include/llama.h) |
MAJOR |
| Backward-compatible features, model support, or API addition | MINOR |
| Bug fix with no API change | PATCH |
The version is set in the three variables at the top of the root CMakeLists.txt:
set(LLAMA_VERSION_MAJOR 0)
set(LLAMA_VERSION_MINOR 1)
set(LLAMA_VERSION_PATCH 0)
A version bump should be included in the PR that introduces the change, or in a dedicated bump commit merged before the release is cut.
TODO: add PR labels (semver: patch, semver: minor, semver: major) to help
identify which PRs require a version bump before cutting a release.
Making a release
Releases are created by running the make-release which is a manual workflow.
The workflow creates an annotated git tag (e.g. v0.1.0) and pushes it to the
remote. No GitHub Release object is created, the tag is the release artifact.
Building a release
By default, LLAMA_BUILD_IS_DEV=ON which appends a -dev suffix to LLAMA_VERSION,
marking the build as a nightly/development build. Distributors building from a
release tag must pass -DLLAMA_BUILD_IS_DEV=OFF to produce a clean version string
(e.g. 0.1.0 instead of 0.1.0-dev).
How releases reach users
Currently releases are not published to github releases, only nightly/development builds are available there. The way users can access releases are using the following channels:
- llama-install.sh — downloads pre-built binaries built from the release tag.
- Package managers — consume the git tag directly.
- Build from source — users clone the repo and check out the tag.