Release

The app is QNTX-App, and how it is released is written there.

Unix-like hosts only — see ADR-029.

What ships

• Docker images: ghcr.io/teranos/qntx:latest and ghcr.io/teranos/qntx:{version}
• Linux CLI tarballs on tagged releases: qntx-{version}-linux-{amd64,arm64}.tar.gz (built natively per arch on amd64 + ubuntu-24.04-arm runners)
• Rolling per-branch pre-releases: on any push to any branch, .github/workflows/branch-latest.yml publishes/updates a pre-release tagged branch-<name>-latest with Linux amd64/arm64 tarballs at a stable URL:

  https://github.com/teranos/QNTX/releases/download/branch-<name>-latest/qntx-<name>-linux-<arch>.tar.gz
  

  For deployments that want the tip of a branch (e.g. a staging host tracking main) without waiting for a tag.
• macOS CLI tarballs on tagged releases: qntx-{version}-darwin-arm64.tar.gz, built on a macos-14 runner. QNTX-App consumes these.
• The browser WASM, ats-wasm-<version>.tgz and laye-p2p-<version>.tgz, which QNTX-Web depends on by this tag. The web bundle itself is built by QNTX-Web's deploy-web.yml, called by whoever is deploying it.

Branch and tag tarballs have the same shape. Linux only, because Linux is what gets deployed.

Every tarball bundles Nix's libduckdb.so in lib/ beside the binary, with the RPATH rewritten to $ORIGIN/lib, so it runs with no LD_LIBRARY_PATH and no wrapper.

libduckdb.so links the host's own libc, and the nixpkgs pin builds it against glibc 2.44: a tarball runs on a Linux host with glibc 2.44 or newer, and not on one older, Debian 13 (2.41) and Ubuntu 24.04 (2.39) among them: "Accepted".

Version

The version is the tag. git describe --tags --match 'v*' --dirty is asked once, in the Makefile, and reaches Nix as VERSION_TAG — which needs nix build --impure, since pure eval cannot read the environment. Without it a binary calls itself dev.