Releases

Releases and the nightly feature

What the version numbers mean, how builds get published, and what turning on nightly actually changes.

Versioning

Every component versions independently.

Component	Notes
lamina	The compiler
lamina-ras	Assembler
lamina-weld	Linker
lamina-ir, lamina-mir, lamina-codegen, lamina-platform	Workspace members, published so lamina can depend on them
lamina-c	Not published. lia_version() returns the crate version

The current numbers are whatever the latest tagged release on each repository says. They are not written down here, because a number written down here goes stale.

The plan is a C ABI version separate from the crate version, since the lia_* symbols and the headers do not have to move with the compiler. That is not implemented yet. lia_version() returns the crate version today.

Nothing here is stable yet. Under 1.0 a minor bump may change the IR text form, the Rust API, or the CLI. 1.0 is the point where that stops being true. It sits far out on purpose: the promise means nothing until every tested target has an end-to-end path and a correctness suite behind it.

The minimum supported Rust version is the one named by rust-version in the repository's Cargo.toml, on edition 2024. It is not repeated here, because a number written down here goes stale.

Release channels

Two kinds of build are published, and they mean different things.

Development builds. Every push to main publishes a GitHub release tagged latest, marked prerelease, titled Development Build (date). The tag is rolling: it is reused, so latest always points at the most recent build of main and never at a fixed commit. Treat it as a snapshot for trying something out, not as something to pin.

Tagged releases. Pushing a version tag publishes a normal, non-prerelease GitHub release. These are the ones to depend on.

The website reads both. The homepage shows the newest tagged release, and separately picks up C SDK archives from the rolling latest tag, which is why the SDK download can be newer than the compiler version shown next to it.

The nightly feature

nightly is a Cargo feature, not a Rust toolchain requirement. Lamina builds on stable Rust either way. Enabling it on the lamina crate turns it on across lamina-ir, lamina-platform, lamina-mir, and lamina-codegen together, so the layers cannot disagree about what exists.

What is behind the gate:

Area	What is behind the gate
Targets	arx64, riscv128 and lisa as architectures, and artery as an operating system. In a default build each is Unknown architecture or Unknown operating system, and an rv128 ISA string is no backend for that RISC-V width. arx64 is an experimental architecture of this project's own, with no silicon and no assembler behind it
Auto-vectorization	The pass that finds vectorizable loops. x86_64 only, --opt-level 3 only
Host SIMD detection	The runtime capability query: which vector extensions the machine running the compiler has
Module annotations	@pic and @pie, in the parser and the builder
JIT	Parts of the runtime compilation path, and the C bindings' JIT extension

Vectors in the IR are not behind the gate. <N x T> as a type suffix, the element-wise operations, the shifts, splat, extractlane, insertlane, shuffle and vector load and store are all in a default build, and so is the x86_64, AArch64 and WebAssembly lowering they go to. Only the pass that produces them automatically is experimental. That asymmetry is the right way round: the surface a frontend writes deliberately is settled, the pass that guesses for it is not.

The rule for anything behind the gate: it may change or disappear in any release, with no deprecation period. If you need something from it, pin an exact version.

A known inconsistency

The documentation describes the JIT as nightly-only, and the C bindings do split that way, with a separate lamina_nightly.h and separate archives. The CLI does not match. --jit runs in a default build. The runtime modules are not gated as a whole. This is tracked in 0.1 under making the story consistent. For now, take the C bindings' split as the accurate description of what is experimental.

C bindings channels

The SDK ships in two archives per target.

Stable carries lamina.h and the AOT surface: build IR through the owned builder, compile to assembly, read errors, free everything explicitly.

Nightly adds lamina_nightly.h and the JIT: compile into executable memory, call through typed helpers, release the JIT handle. Kept in a separate header so a stable consumer cannot reach an experimental entry point by accident.

Header generation is hand-maintained rather than produced by cbindgen, because cbindgen does not yet understand #[unsafe(no_mangle)] under the Rust 2024 edition. Nothing rebuilds the C examples yet, so the headers and the exports can drift apart. See 0.1.

What "tested" means on a release

A target being listed does not mean a release was verified on it. The 0.2.0 testcase suite passes all 176 cases on ubuntu-latest, windows-latest and macos-latest (arm64), and those are native runs of the generated code. s390x is executed too, under QEMU user-mode emulation against its cross C library, which is a real run of the generated code and not a run on z hardware. There is no x86_64 macOS runner in that list, so x86_64_macos is not run. The entries in the target table marked Run are the ones with a checked run. The rest are compiled, or compiled and assembled, and not run. Closing that is the open part of 0.1.