Release notes
| Version | Date | Notes |
|---|---|---|
| 0.1.0 | — | The first release. Not yet published. |
How versions work
The runtime follows Semantic Versioning. Three things about that are worth stating early, because they are the ones that surprise people.
A bump to the minimum supported Rust version is a minor release, not a major one. It is also the most common reason a downstream build breaks after an upgrade, so it is always called out at the top of a release’s notes rather than left to a table.
The model’s schemaVersion is separate from the runtime’s version. A
runtime knows which schema versions it can read; a model declaring one it does
not know is refused at load rather than half-understood. A new schemaVersion
is a major release.
Diagnostic codes are permanent. A code is never reused and never renumbered,
so M203 in a script, a ticket or a runbook means the same thing forever. A
retired check takes its number out of circulation with it.
What counts as breaking
For a product whose whole surface is generated from a customer’s model, “public API” needs defining. These are breaking, and only appear in a major release:
- A change to the authored model format that makes an existing valid model invalid.
- A change to the HTTP surface that makes an existing correct client wrong — a status code, a response shape, a header a client must send.
- A schema change the runtime makes to an existing database that is not additive.
- Removing a diagnostic code, or changing what one means.
These are not breaking, though they may still be worth reading about:
- A new diagnostic that rejects a model which was previously accepted and wrong. Validation getting stricter about genuine mistakes is the product working.
- Changes to log lines, span attributes or metric descriptions. Instrument names and metric labels are stable; the prose around them is not.
- Anything in the runtime’s internal crates. They are published so the binary can be built, not as a library to depend on.
Upgrade order
Always the same, and the reason is that migrations are additive:
runtime db plan— safe against production, and what a reviewer reads.runtime db apply— the old version keeps working, because the change is additive.- Roll the new runtime out.
A pod serving a model the database has not been provisioned for fails readiness and takes no traffic, which is what makes a rolling deploy wait rather than serve errors. Upgrading has the detail.