Changelog

Releases

• 0.0.0. The scaffold · 2 September 2026

There is one entry, and it describes a documentation site with no components in it. State of the system is the page that says what that means in practice.

A feed of these entries is published at /rss.xml.

How entries are written

One file per release, named by date, so the newest is always first without anybody maintaining an order.

Breaking changes first. Not in a section at the bottom labelled "notes". If a release changes something you have already built against, that is the first thing on the page, and it names the version that introduced the change and what to do about it.

Prose, not commit subjects. A list of merged pull-request titles is a record of what the maintainers did. An entry is a description of what changed for the person reading it, which is a different document and takes longer to write.

Every entry says what did not change, where that is the interesting part. That matters particularly for the surfaces the versioning policy covers beyond the JavaScript API: the rendered DOM, the data-* attributes and the CSS custom properties.

A changed clinical default leads the entry, on its own line, labelled SAFETY. Not in a bullet list with the refactors, and not below the fold. The change this rule is about is a presentation change: a status word, a default rounding or unit, a colour pairing, an aria announcement, or the wording of an uncertainty or staleness note. opsinjs owns no clinical threshold and an entry must never read as though it does. What it owns is how a value someone else decided is shown to a patient, and changing that changes what a person believes about their own health. This is a rule rather than a convention because of how the code is distributed. A consumer who copied the file does not receive the change when it ships. They receive it when they next copy the file, which may be never. The entry is the only thing that can tell them a safety change is sitting upstream waiting.

What belongs somewhere else

A deprecation appears here when it happens and lives on Deprecations until it is removed, so that the current list is one page rather than an archaeology exercise across entries.

A change needing more than a paragraph to migrate through gets a written guide, linked from the entry. The versioning policy says which four kinds of change earn one. Entries stay readable; guides get as long as they need to be.

The reasoning behind a change, where it is architectural, belongs in a decision record. An entry says what changed; a record says why, and survives being read three years later.

Edit this page

Last read through against the system on 2026-09-20. Due for review every 6 months; expiry is reported by pnpm run check:freshness.