Truss v0.0.47

Truss v0.0.47

Release scope

Restores explicit forward runtime migration
for populated UMF 0.10 databases. Only the latest application runtime is supported;
previous databases are supported by migrating forward to it. Older application
runtimes, pre-0.10 migration and downgrades remain outside support.

Python 3.11+, PostgreSQL 18.6, psycopg 3.3.6, mini-racer 0.14.1, UMF 0.10 and
Weft 0.4.49 form the selected tuple. Native 0.73-candidate has manifest SHA-256
7ac989147f22d437b1ce0d814ebbfaa25aa868ab5495de125aa5e2bda7b963ea.
Business layout 1.0 remains unchanged; the immutable administrative receipt
adjunct is modeled separately through UMF and included in the exact inventory.

Audience and changes

Python embedders use truss.migrations.RuntimeMigrations or truss-migrate.
Operators use the package guide
and execution plan. This release
also adopts the published v0.0.46 private local PostgreSQL socket/environment
isolation baseline.

The admitted native sources are v0.0.44 and the identical v0.0.45/v0.0.46 tuple.
Exact manifest, native definitions, privileges and metadata-owner configuration
decide admission. Changed or unknown installations refuse before migration effects.
Application startup never migrates. Old-wheel operations refuse after commit.

The administrative tool owns its transaction and persists original attempt
custody in a restart-durable host registry before submission. Receipts retain
complete original request, recipe, inventory, ordered effects and preservation
bytes. Actual lost COMMIT responses reconcile the same attempt without repeating
steps. A known commit with unavailable verification remains committed-unverified.

Required actions and recovery

1. Quiesce writers and back up the database together with its host recovery registry.
2. For the qualified logical dump/restore workflow, save backup-metadata too.
   PostgreSQL 18.6 omits private table-row-type ACLs; explicitly apply that original
   companion during offline restore before verification or application access.
3. Run status, then prepare and retain the returned reference. Run apply with
   that reference. Reconcile uncertainty with the same reference, then verify
   before resuming latest application work.

Default limits are 256 MiB per preservation pass, 10s per statement and 30s per
operation. Larger finite limits are explicit and require workload qualification.
Failure before commit rolls back the initial route. After commit use a forward
fix or the qualified backup restore/remigration flow; installing an old package
is not database rollback. Original receipt lookup remains in latest tooling.

Qualification and known limits

The original evidence
records local macOS ARM64 installed-wheel migration checks, focused regressions,
package byte correspondence and module controls. Populated original wheels seed
keyed objects, retained unknown/null content, edge/history, import provenance,
mutation replay and a committed feed acknowledgment. Native fingerprints cover
all original table/sequence state; independently authored API assertions verify
latest reads, primary/alternate key lookups, writes and continuation.

The final installed migration matrix passes all 52 cases without skips on local
macOS ARM64 and hosted Linux x86_64; source-bound Linux receipt
and package correspondence
verify all 445 runtime payload files in the wheel and sdist. The complete
Linux release workflow
also passes selected installed-runtime workflows and the original 1,000-object/
1,000-edge public workload under unchanged SQL/operation limits. Publication
requires the tag workflow to repeat these gates at the merged source; its original
migration receipt and native evidence archive ship with the checksummed assets.
The execution plan records publication and subsequent public-install verification.
Optional large-capacity/stress jobs and broad discovery are outside this result.
Protected query profiles, pre-0.10, managed services, physical restore/incarnation,
large-database capacity and exhaustive scalar/container/ownership migration
corpora are not claimed. Logical restore evidence covers a new database identity
before target writes, followed by migration from either admitted source.

Every future release must keep all admitted sources reachable with the latest
tool, retain immutable published artifacts and archive original manifests. A
package-only unchanged tuple requires no-change evidence. The first real
subsequent edge must add native skip-release-chain execution proof; the current
pure graph test does not establish that future result.