The gap
There is no released version of morphic, and the README says so plainly:
There is no released version — the IR schema and the CLI surface are unstable and may change between commits.
That is the right posture for a compiler in early development. It stops being workable the moment something downstream stores IR documents.
Why it comes up now
dexpace/spaceapi is evaluating morphic IR as its input format (spaceapi#56) — not as a build-time convenience, but as the thing it persists per released API version and reads back later to render and diff. A consumer in that position needs to answer three questions, and today it cannot answer any of them:
- What do I pin? There is no tag and no module version, so the only honest answer is a commit SHA.
- What produced this stored document?
ir.Document carries irVersion (0.3.0), which is the right hook — but nothing says what an irVersion bump promises or forbids, so a consumer cannot tell a field addition from a field rename.
- When must I regenerate? Without an answer to (2), the safe answer is "on every morphic commit", which for a consumer holding 30 MB documents per version is not a real answer.
What would be enough
Not semantic versioning of the whole project, and not API stability promises the project is not ready to make. Something much smaller:
- A tag. Even
v0.1.0 on a commit whose gate was green gives a consumer something to name.
- A statement of what
irVersion means. Roughly: what kind of change bumps it, whether a bump is ever backward-compatible, and whether a document at version N can be read by a build expecting N+1. ir/document.go already records the rename from preserved to unmodeled at 0.3.0, so the field is clearly intended to carry exactly this — it just has no documented contract.
- Optionally, whether stored IR is expected to be regenerable rather than migrated. If the answer is "always recompile from source, never migrate a stored document", that is a perfectly good answer and it makes the other two questions much cheaper — but it needs saying, because a consumer that keeps the source specs around will design differently from one that does not.
Related
Raised by dexpace/spaceapi while scoping an IR integration, 2026-09-07.
The gap
There is no released version of morphic, and the README says so plainly:
That is the right posture for a compiler in early development. It stops being workable the moment something downstream stores IR documents.
Why it comes up now
dexpace/spaceapiis evaluating morphic IR as its input format (spaceapi#56) — not as a build-time convenience, but as the thing it persists per released API version and reads back later to render and diff. A consumer in that position needs to answer three questions, and today it cannot answer any of them:ir.DocumentcarriesirVersion(0.3.0), which is the right hook — but nothing says what anirVersionbump promises or forbids, so a consumer cannot tell a field addition from a field rename.What would be enough
Not semantic versioning of the whole project, and not API stability promises the project is not ready to make. Something much smaller:
v0.1.0on a commit whose gate was green gives a consumer something to name.irVersionmeans. Roughly: what kind of change bumps it, whether a bump is ever backward-compatible, and whether a document at version N can be read by a build expecting N+1.ir/document.goalready records the rename frompreservedtounmodeledat 0.3.0, so the field is clearly intended to carry exactly this — it just has no documented contract.Related
Unmodeledkey names are an unversioned contract that consumers are currently forced to read.Raised by
dexpace/spaceapiwhile scoping an IR integration, 2026-09-07.