Radiator software releases

Build and release types for Radiator server binaries

Radiator releases tested and documented software at regular intervals. This document explains our conventions for producing high quality software.

There are four build kinds of software releases described below.

release

The official release of the software. Fully tested through our automated test frameworks. Releases also have complete release notes.

  • Produced several times per year.
  • Security vulnerabilities may trigger an additional patch / point release of an older version.

Use this for production environments.

nightly

Nightly build of the current software. This runs through the same automated test suites as production releases.

Security fixes are not backported to older nightly builds; instead you should pick up the latest nightly that contains the fix.

Customers with access to nightly builds can use them to test upcoming functionality early (e.g. staging / QA environments) and to validate upgrade paths. It is possible to run these in production temporarily, but migration to a release build is recommended as soon as practical.

We often run demo sessions using nightly builds.

Almost all changes present in nightly builds land in the next release (occasionally a change may be reverted before a release if issues are found).

development and dirty

development and dirty builds should not be used for production. A development build is typically produced with a debug profile (or a non‑release profile) during rapid iteration or local feature work.

A dirty build contains "hot code": uncommitted (or modified but uncommitted) changes present in the working tree at build time. Such a binary may not be reproducible from any commit and may not have passed the full test suite.

Visibility of build kinds

Radiator embeds a build identity (build_kind) into every binary. This is visible via:

  • Command line: radiator --version
  • Logs: startup texts
  • Management API: build info endpoint
  • Prometheus metrics: radiator_build_info{build_kind=...}
  • Web UI: status / summary cards

Additional metadata:

  • Build timestamp (e.g. 2025-09-18T09:50:11Z) – UTC, second precision; reproducible if SOURCE_DATE_EPOCH is set.
  • CPU / target triple (e.g. aarch64-apple-darwin).
  • Git branch and short commit hash (always included; helpful for traceability, especially for development / dirty).
Navigation
Home