Versions, Releases, and deployment
Ormuz deployable artifacts share the same versioning model: every meaningful save produces an immutable snapshot, the Working pointer advances to the current snapshot, a Release explicitly publishes a snapshot, and live deployment relies only on Releases.
Shared lifecycle
Editing advances Working to an immutable snapshot. Promoting that snapshot creates a durable milestone, then a Release can be deployed live.
This model applies to Processes, Forms, Decisions, Agents, External Tasks, and ProcessLaunchers. Pages for each artifact describe their executable content; this page defines the shared versioning contract.
Working and immutable snapshots
Working is not a version edited in place: it is a pointer to the immutable revision currently selected by the editor. When a save genuinely changes versioned content, Ormuz creates a new revision and moves Working to that snapshot.
Content is identified by its canonical hash. Saving again without changing this content reuses the existing Working snapshot; save timestamps are not part of versioned content and therefore do not alone create a new revision.
Snapshots provide fine-grained history during design and testing. They are not the mechanism for durably preserving a version: that role belongs to Releases.
Release and live deployment
Promoting a snapshot creates an immutable Release referencing exactly that revision. A Release is an explicit, durable milestone and is not removed by automatic snapshot retention.
A live environment does not accept a floating Working dependency. Deployment must resolve the Process and its versioned dependencies to snapshots published as Releases so the contract remains reproducible.
If a working state must remain durably addressable, promote it to a Release. An ordinary historical snapshot may be compacted once no reference protects it.
Working-snapshot retention
Ormuz automatically compacts ordinary snapshots so one editing session does not produce hundreds of low-value checkpoints. For each artifact, the platform keeps:
- the 5 most recent ordinary snapshots;
- the latest ordinary snapshot of each UTC day for the previous 10 days;
- in addition to these quotas, any snapshot protected by its role or an existing reference.
The same snapshot may satisfy both the five-most-recent rule and the daily rule. Compaction never renumbers history: revision numbers remain monotonic even when some older snapshots are no longer retained.
Snapshots still referenced
Retention does not remove a snapshot that still participates in a reproducible contract. This notably includes the Working snapshot, every snapshot published as a Release, and revisions still referenced by an execution, Run, another versioned artifact, deployment history, or a draft depending on that base.
The lifetime of these references is independent from the 10-day window: while the reference exists, the snapshot remains available. Once it disappears, the snapshot becomes eligible for normal compaction again.
For artifact-specific detail, see Process, Forms, Decisions or Agents.