Skip to content

cmake : introduce semantic versioning (wip) [no ci] - #26839

Merged
danbev merged 19 commits into
ggml-org:masterfrom
danbev:semver
Aug 12, 2026
Merged

cmake : introduce semantic versioning (wip) [no ci]#26839
danbev merged 19 commits into
ggml-org:masterfrom
danbev:semver

Conversation

@danbev

@danbev danbev commented Aug 10, 2026

Copy link
Copy Markdown
Member

Overview

This commit introduces semantic versioning in llama.cpp.

Additional information

This is a work in progress to figure out how this will work for llama.cpp. An example of building and installing llama.cpp to verify this can be found in examples/test-make. The README.md in that directory contains some in-progress notes.

Refs: ggml-org/ggml#1582
Refs: ggml-org/ggml#1579
Refs: make-release.yml runs on fork

Requirements

@github-actions github-actions Bot added documentation Improvements or additions to documentation build Compilation issues devops improvements to build systems and github actions mtmd Related to multimodal functionality (video/image/audio) labels Aug 10, 2026
Comment thread .github/workflows/release.yml Outdated
Comment thread .github/workflows/make-release.yml Outdated
Comment thread .github/workflows/make-release.yml Outdated
Comment thread examples/test-cmake/README.md Outdated
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.
Comment thread .github/workflows/make-release.yml Outdated
danbev and others added 4 commits August 12, 2026 07:04
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 (08c69e3)
...
```

Refs: ggml-org#26839 (comment)
@danbev

danbev commented Aug 12, 2026

Copy link
Copy Markdown
Member Author

I've tested this by running the following on my fork...

A simplified release.yml workflow:

Then manually ran the make-release.yml workflow:

Note: I disabled the ggml check for the above run as it failed otherwise (correctly), as there are currently changes in the internal ggml that are not yet in upstream ggml. But the main point was to verify the nightly build check and tagging.

@github-actions github-actions Bot added the testing Everything test related label Aug 12, 2026
Comment thread CMakeLists.txt
Comment thread .github/workflows/make-release.yml Outdated
@ggerganov

ggerganov commented Aug 12, 2026

Copy link
Copy Markdown
Member

Let's add a TODO to the winget workflow to update it to publish releases instead of development builds. Currently, it will pick up and submit the dev releases:

- name: Find latest release
id: find_latest_release
uses: actions/github-script@v8
with:
script: |
const { data: releases } = await github.rest.repos.listReleases({
owner: context.repo.owner,
repo: context.repo.repo,
});
const { tag_name: version, assets: assets } = releases.find(({assets}) => assets.find(asset => asset.name.includes('win-vulkan')));
const { browser_download_url: asset_url } = assets.find(asset => asset.name.includes('win-vulkan'));
console.log("Latest release:", version);
core.setOutput('VERSION', version);
core.setOutput('ASSETURL', asset_url);

It's fine - we will fix it later. Just not to forget to do it.

@ggerganov

Copy link
Copy Markdown
Member

Seems mergable IMO. Anything left on your end?

@danbev
danbev marked this pull request as ready for review August 12, 2026 10:39
@danbev
danbev requested review from a team as code owners August 12, 2026 10:39
@danbev

danbev commented Aug 12, 2026

Copy link
Copy Markdown
Member Author

Seems mergable IMO. Anything left on your end?

I don't think so, I'll make the ggml PR read for review as well now.

@danbev

danbev commented Aug 12, 2026

Copy link
Copy Markdown
Member Author

@ggerganov What are your thoughts on handling the bumping of the versions. Should this be done per PR where it is appropriate depending on the types of changes?

@ggerganov

ggerganov commented Aug 12, 2026

Copy link
Copy Markdown
Member

Every PR can bump the version accordingly, but realistically we are not going to be doing that. It will be difficult for contributors who are not deeply familiar with the project to make the decisions about the version updates. And us asking them to do it on each PR will get too compicated.

The important part is when we decide to make a new release to take a look at the changes that have accumulated since the previous release, and based on that to update the llama.cpp version accordingly and put the release tag. The downstreams will eventually be building from the tagged versions, so it's not a problem if the code in-between two official versions does not have the correct LLAMA_VERSION.

@CISC

CISC commented Aug 12, 2026

Copy link
Copy Markdown
Member

Can we publish some automated Changelog somewhere? Just grab the commit titles between releases and make sure the PR links are links...

@ggerganov

Copy link
Copy Markdown
Member

Can we publish some automated Changelog somewhere? Just grab the commit titles between releases and make sure the PR links are links...

I think we can simply make Github releases for the semver tags same as we do for the development releases currently in release.yml, and include the git log in the body.

@ggerganov ggerganov left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can do the changelog either in this PR or in a follow-up. Up to @danbev

@danbev

danbev commented Aug 12, 2026

Copy link
Copy Markdown
Member Author

We can do the changelog either in this PR or in a follow-up

Lets do it in a follow up if that is alright.

@danbev
danbev merged commit 680a9ae into ggml-org:master Aug 12, 2026
1 check passed
@danbev
danbev deleted the semver branch August 12, 2026 12:15
gabe-l-hart added a commit to gabe-l-hart/llama.cpp that referenced this pull request Aug 12, 2026
Signed-off-by: Gabe Goodhart <ghart@us.ibm.com>

* origin/master: (383 commits)
  cmake :  introduce semantic versioning  (ggml-org#26839)
  gguf : harden loader against malformed tensor dims and metadata types (ggml-org#25596)
  kleidiai: Add runtime feature detection mechanism for aarch64/kleidiai (ggml-org#26076)
  model : disallow integer dflash sliding_window_pattern (ggml-org#26900)
  sync : ggml
  cmake : add config version support (ggml/1582)
  server : support slot save/restore with media inputs (ggml-org#26640)
  ui: add read_media tool (ggml-org#25877)
  opencl: default FA c8 cluster width to 16 on X1E (ggml-org#26433)
  tests : update speculative params (ggml-org#26925)
  vulkan: add TQ2_0 (ternary) support (ggml-org#25850)
  wavtokenizer-dec : bound posnet/convnext block_count against n_layer_all (ggml-org#26892)
  convert : handle per_layer_config in Gemma4 (transformers 5.15) (ggml-org#26882)
  opencl: use flat mv q5_k when weight exceeds image1d_buffer_t limit (ggml-org#26880)
  chat : fix muse-glimmer detection of tool calls after EOM (ggml-org#26879)
  ci : add missing release check (ggml-org#26923)
  CUDA: only disable CUDA graphs when mul_mat_id actually needs a stream sync (ggml-org#26802)
  cuda : add warp-per-row wkv7 kernel for single-token decode (ggml-org#26111)
  spec : update speculative-simple (ggml-org#26904)
  chat : tighten bare function parsing for Qwen models (ggml-org#26793)
  ...
@ngxson

ngxson commented Aug 12, 2026

Copy link
Copy Markdown
Collaborator

Thanks @danbev for taking the lead on this. I just have a deeper look on this PR and I agree to all points we have been discussing so far.

Re changelog, let's add it via a dedicated PR. Maybe we can start simple by writing a list of commits as changelog, then later on having a skills or utilize llama-server via pi agent SDK to write a better summarize for each version. TBD

@ngxson

ngxson commented Aug 12, 2026

Copy link
Copy Markdown
Collaborator

Also, for versions that require major number bump, I'd suggest assigning "breaking change" label for it. Maintainer should be responsible assigning the label ideally before merging the PR

https://github.com/ggml-org/llama.cpp/issues?q=state%3Aopen%20label%3A%22breaking%20change%22

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build Compilation issues devops improvements to build systems and github actions documentation Improvements or additions to documentation mtmd Related to multimodal functionality (video/image/audio) testing Everything test related

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants