7c35571e5d
* ci : allow make-release to target a specific commit The make-release workflow now accepts an optional 'commit' input. When set, that commit is checked out and the release checks verify that it belongs to the branch selected in the "Run workflow" dialog and is not older than 3 days from the branch tip. The check is part of make-release-checks.sh (driven by the RELEASE_BRANCH env), so it follows the same dry-run semantics as the other checks. Assisted-by: pi:llama.cpp/Qwen3.8-27B * cont : scan latest 100 relase workflow runs * cont : do not check manually for release.yml success
2.2 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 runs against the branch selected in the "Run workflow" dialog
(default master) and takes an optional commit SHA. When a commit is given,
the workflow validates that the commit belongs to the branch and is not older
than 3 days from the branch HEAD, then releases that commit instead of the
branch HEAD.
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.