Versions and Releases
How releases are numbered, what each one publishes, and how to check a download. What each release changed is in the CHANGELOG.
Versions
A release is tagged <llvm version>.<revision>. 23.1.2.1 is the first build of LLVM 23.1.2, 23.1.2.2 the second. The version sorts the way conda, Bazel and CMake sort versions, and says which LLVM it is.
Nothing published is ever replaced. A fix to a release, even one that only rebuilds it, is the next revision, and the workflow that drafts a release refuses a version that exists. So a version, and the sha256 of each of its archives, means one thing forever. Pinning by digest relies on that, in the versions.bzl of the Bazel module and in the CMake download.
A fix of the packaging alone, such as the Bazel module, the CMake package or the config files, is a repack: the next revision, whose compiler and runtimes are those of the release before it, the same bytes.
Every channel has the release under its version, and a way to the newest:
| where | version | the newest |
|---|---|---|
| GitHub release and tag | <version> | releases/latest, whose SHA256SUMS names its archives |
| conda package | <version>; the build number counts packaging fixes of the release, each the same toolchain packaged again | xclang = "*" |
| Bazel module | <version> | Bazel takes the newest version a module of the build asks for |
| CMake FetchContent | the tag <version> | the branch latest, at the tag of the newest release |
Assets
Every GitHub release has the same 17 assets:
| asset | size (23.1.2.8) | |
|---|---|---|
xclang-<version>-<host>.tar.xz | the toolchain, one per host, every target in each | 86 to 94 MB |
libclang-<version>-<host>.tar.xz | the static libraries and headers of clang and LLVM, one per host (libclang) | 258 to 272 MB |
libclang-<version>-<host>-asan.tar.xz | their ASan build, for Linux x64 and macOS arm64 | 189, 209 MB |
llvm-option-inc-<version>.tar.xz | the option tables of clang, lld, llvm-lib and llvm-dlltool | 185 KB |
xclang-<version>.profdata | the PGO profile the release was built with | 52 MB |
SHA256SUMS | the sha256 of every other asset |
The hosts are x86_64-unknown-linux-gnu, aarch64-unknown-linux-gnu, x86_64-w64-mingw32, aarch64-w64-mingw32, aarch64-apple-darwin and x86_64-apple-darwin.
Checking a Download
The workflow that drafts the release writes SHA256SUMS from the files it uploads. This checks a download of the newest release against it (gh release download <version> for another):
gh release download -R clice-io/xclang -p SHA256SUMS -p 'llvm-option-inc-*'
sha256sum -c --ignore-missing SHA256SUMSThe Bazel module checks every archive against the sha256 that its versions.bzl pins. The xclang.cmake of the CMake package checks the toolchain against the SHA256SUMS of the release.
Both are as trustworthy as the release. An archive and the SHA256SUMS beside it could in principle be replaced together. A pin in versions.bzl, or a digest recorded in a project of its own, is not affected by that. Immutable releases are planned.
Where Else a Release Is Published
- conda: conda.clice.io has the
xclangpackage for each host, and the noarchllvm-option-inc. They are made from the archives of the release after it is published (installation). - Bazel: bazel.clice.io has the module of the tag, published once it builds and tests with the published archives (Bazel).
- CMake: FetchContent checks out the tag itself (CMake).
How a release is built and tested is in the build pipeline.