Manage compatibility and trusted releases

Compatibility policy

Runifold publishes a synchronized version across public crates and supports Rust 1.88 as its declared MSRV. Before 1.0, breaking public API changes require a minor release; after 1.0 they require a major release. SemVer checks supplement review but cannot prove behavioral compatibility with Providers, Stores, prompts, or persisted state.

Consumer upgrades

Applications should pin pre-1.0 versions, review the changelog and RFC status, compare Cargo Features, compile under the supported Rust and target matrix, and run their own model, Store, recovery, evaluation, and browser evidence.

Upgrade durable Workers gradually. Keep old Workflow definitions available until no active state requires them. Back up before Store migrations and verify rollback.

Upgrade to 0.9.0

0.9.0 adds deterministic and Agent-backed review gates for internal plans, terminal Agent output and workflow generation. It also includes the 0.7 Provider Runtime profiles, operations CLI, media tasks, hosted OpenAI Tools, reranking, hybrid retrieval and text ingestion, plus the 0.8 strict-schema and review-gated workflow work.

This is a pre-1.0 breaking upgrade. Move concrete Provider dependencies and imports from facade Features to runifold-providers; compatible brands now share the openai protocol Feature. Durable Workflow checkpoint writers emit schema v5 from 0.8 onward: drain 0.7 workers before new workers advance any checkpoint. Reviewer name, version, rubric, policy and capabilities become recovery-bound state, so deploy those changes as workflow-definition changes.

[dependencies]
runifold = "=0.9.0"
runifold-providers = { version = "=0.9.0", features = ["openai"] }

Artifact gates

Release CI tests stable Rust and MSRV, formatting, lint, tests, docs, packaged crate contents, temporary-registry resolution, public API compatibility, RustSec advisories, license allowlists, and dependency sources.

Each release includes .crate archives, CycloneDX SBOMs, and SHA-256 checksums. Consumers should verify the tag, checksum, crate provenance, and dependency policy rather than trusting a source-tree badge.

Publication boundary

Creating signed tag artifacts and publishing immutable crates.io versions are separate authorization boundaries. Publication is manually confirmed, dependency-first, and restartable. Never publish from a branch or dirty worktree.

This separation allows artifact inspection before irreversible registry mutation.

Failure recovery

A failed artifact build requires a new corrected version and tag; do not move a tag users may have observed. A partial workspace publication reruns the same workflow, skips versions already present, and resumes dependency order. An incorrect published crate is yanked if necessary and fixed forward—registry versions cannot be overwritten.

Verify a 0.9.0 upgrade

Update one package deliberately, inspect the resolved graph, and preserve the lockfile in the review:

cargo update -p runifold --precise 0.9.0
cargo tree -i runifold
cargo tree -i runifold-providers
cargo check --locked --all-targets
cargo test --locked --workspace
cargo clippy --locked --workspace --all-targets -- -D warnings

Then exercise schema-v3/v4 checkpoint reads, schema-v5 writes after old workers are drained, reviewer-ready and reviewer-in-flight recovery, rich Tool results, each enabled Provider, and every deployment target. If rollback is required, restore both the old binary and a Store snapshot proven compatible with it; changing only the Cargo version cannot undo a migration. Keep old Workflow versions registered until no active checkpoint references them.