How it works | Lithespan

A Lithespan release links one build to its target, tests, evidence, outputs, and support term.

Define the release

Six fields define the work:

Software: source, version, dependencies, toolchain, and build options
Hardware: architecture, required features, accelerators, and fleet constraints
OS: distribution, kernel, libc, system ABI, and required services
Workload: performance, memory, startup, compatibility, or another measured goal
Format: container image, machine image, native package, binary, archive, or another tested output
Support: update scope, response terms, and end date

Targets can be portable, architecture-specific, accelerator-aware, or tuned for a particular fleet.

Move one payload through four stages

Define: agree the software, target, workload, format, and support term.
Build: produce a traceable payload from pinned inputs.
Test: run workload, compatibility, security, upgrade, rollback, and failure tests.
Maintain: track source changes, rebuild when needed, and repeat the evidence.

A stable release reuses the tested build; promotion changes its status, evidence, and support commitment.

What stays attached to the release

Performance evidence Benchmarks include enough context to reproduce the comparison.

Reports state the workload, hardware, OS, kernel, duration, warm-up, concurrency, dataset, sample count, variance, and baseline. They include regressions and trade-offs. Goals may cover throughput, latency, memory, startup, cost per unit of work, or compatibility.

Security and supply chain Source, build inputs, signatures, and vulnerability handling are part of the release.

A release record can include pinned source and dependencies, reproducible builds, SPDX or CycloneDX SBOMs, signed provenance, checksums, immutable references, and upgrade, rollback, and failure tests.

Maintained releases are rebuilt and tested when relevant fixes apply. Public issue handling is best effort; paid scopes can add response times and private advisories.

To report a vulnerability, email contact@lithespan.com with the release reference, platform, architecture, and enough information to assess the issue. Do not include sensitive customer data in the first message.

Maintenance and support Each stable target names its owner, support boundary, and end date.

Public stable releases state their version line and support window. Artifacts and evidence are free; community support is best effort.

Paid agreements can add private targets, rebuild schedules, regression reports, controlled distribution, response times, and performance or compatibility obligations. Time-bound extensions may be available after upstream support ends.

Formats and distribution Packages, container images, and machine images point to the same tested release.

Outputs can include OCI images, AMIs, Azure managed images or VHDs, Google Cloud custom images, qcow2, OVA, signed native packages, archives, and Nix outputs. Each format points to the same tested build.

Machine images can include the agreed OS, kernel, drivers, runtimes, libraries, and application configuration. Public artifacts need no account. Customer-specific images are delivered privately into the customer’s account or repository.

Upstream policy

Changes stay narrow and reviewable. General improvements move upstream when practical.