Releases

Documents the atlasd v0.2 release lineView as Markdown

Atlas releases are versioned, signed and attested as a unit: one tag produces the binaries, checksums, signatures, provenance and SBOMs for every target, published together. This page describes the release discipline; the artifacts themselves live behind Downloads.

Current release

Release lineStatusNotes
v0.2currentThe release line this documentation describes. Supply-chain attestation (signatures, SLSA L3 provenance, SBOMs) is fully implemented in CI as of v0.2.

Nexus Atlas is in active, rapid development ahead of a 1.0: expect substantive features per release line, and read release notes rather than assuming semantic stability before 1.0. Evaluation deployments are expected to track the current line.

What every release contains

  • Static atlasd binaries per target (x86_64 and aarch64 Linux), each with an embedded dependency manifest.
  • .sha256 checksums, cosign keyless signatures with certificates, SLSA L3 provenance, and CycloneDX SBOMs — the full set the verification recipe consumes.
  • Release notes covering: features and changes, configuration keys added or changed, protocol version implications, any accepted dependency advisories with rationale, and known issues.

Compatibility rules you must plan around

  • Protocol version is checked, not negotiated. Every packet carries a protocol version byte; mixed versions fail loudly at decode. Upgrade a deployment as a deployment — release notes flag every protocol-version bump prominently, and mixed-version operation across a bump is not a supported state.
  • Configuration is stable-by-schema. The config surface is defined by the daemon's own generated schema (the reference regenerates from it). Deprecated keys keep working with warnings for at least one release line before removal; atlasd config check is the authority on any given binary.
  • Wire-compatible opt-ins stay opt-in. Features documented as default-off (traversal, transport classes) do not change the wire behavior of nodes that leave them off.
  • Legacy paths linger deliberately. Pre-rename config, snapshot and socket paths remain honored via fallbacks so staged fleet upgrades never race a rename.

Release notes & notifications

Release notes are published with each release under Downloads. Organisations with approved access are notified of new releases and of any security-relevant advisory affecting a shipped release at the contact on their access request.

Verifying is not optional ceremony: run the verification recipe against every artifact you ingest, and pin the identity strings from the release page in your scripts. A release you didn't verify is a release you're trusting your download path with.
Esc
↑ ↓ navigateEnter — openEsc — close