Release and rollback

Defines coordinated but independent MiRust guide and GGUF implementation versions, source/artifact manifests, deployment gates, and rollback evidence.

Experimental
Last verified
2026-06-25 00:00 UTC
Updated
Reading time
2 minutes

Defines coordinated but independent MiRust guide and GGUF implementation versions, source/artifact manifests, deployment gates, and rollback evidence.

Implementation evidence: this topic is grounded in the reviewed GGUF.MiRust.com source snapshot. It documents observed code and artifacts without claiming broad deployment, model quality, or production readiness.

Independent versions

MiRust theme/plugin/content 1.5.0 documents GGUF implementation workspace 0.1.0 from the 2026-06-25 source snapshot. The numbers do not imply a coordinated executable release.

Implementation release bundle

Record source revision/archive hash, Cargo lockfile, Rust toolchain, WASM hash, every model and manifest hash, build/test logs, quality scope, license review, browser support, memory/latency measurements, known limitations, and migration notes.

Deployment gates

Clean build, full tests, format fuzzing, artifact signature verification, worker responsiveness, browser matrix, accessibility of the operator UI, quota/eviction behavior, error recovery, and no-network privacy audit.

Rollback

Retain previous app/WASM/model/manifest set under immutable versioned paths. Activation must be atomic. If a new runtime rejects or mishandles cached artifacts, restore the complete known-compatible set rather than mixing versions.

Guide release

MiRust content updates only starter-managed pages proven unedited. Owner-edited documentation remains intact; newly introduced docs and model profiles are added without deleting content.

Scope

This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.

Engineering considerations

  • Identify the source, version, target environment, and owner.
  • Separate observed values from estimates and externally reported values.
  • Record trade-offs, unsupported cases, and fallback behavior.
  • Link performance statements to a compatible benchmark methodology.

Verification questions

  • What exact artifact, revision, backend, and environment were reviewed?
  • Which assumptions could change the result?
  • Which data should be retained so another engineer can reproduce the conclusion?