Versions & releases

Channels and pinning

Releases publish signed, checksummed platform bundles plus channel metadata; installs and tarski self-update resolve versions through https://download.getjacqos.com/channels/<channel>.json and verify assets against checksums.txt. The former-project hostname remains only as the bounded release transport origin while that infrastructure migrates. Pin a version with TARSKI_VERSION. The current line is the preview channel, at v0.5.9-preview.

Immutable, cache-neutral releases

• Immutable: a tag’s assets never change. Defects get a new correction release — never a mutated artifact under an old version.
• Cache-neutral: build caches can never change what ships; cached and uncached artifact digests must match, release-blocking.
• Gate-verified: every release proves the end-to-end CLI journeys — install, login, publish, observe, export, restore, and replay — before it publishes, and cross-engine evaluation parity is release-blocking.

Managed Cloud converges with releases: after a deploy, the management and runtime planes report the same normalized version, and the production health endpoint exposes schema state, service version, and serving image digest as public metadata.

Version identity in your apps

Platform versioning never blurs into semantic identity. Your app’s behavior is identified by its evaluator digest and package digest — a platform upgrade cannot silently reinterpret an existing activation, and workspace runtime upgrades are explicit, receipted operations with rollback. See Worldviews & lineages.

Distribution profiles

The public tarski CLI is the app-developer surface — it does not embed the protected local evaluator. A full local-runtime profile exists for entitled development, BYOC, and conformance work as a separately distributed artifact. Hosted runtime images are internal deployment artifacts. If a preview release intentionally omits a platform, installers report an explicit availability diagnostic rather than a broken download.