Release notes that a consumer can actually act on: filter to just the breaking changes, see security fixes called out, and find out immediately when a release has been withdrawn.
Patch release. Fixes a manifest signing regression introduced in 3.4.0.
Adds Rust bindings and the ML-KEM hardware path.
Withdrawn: introduced a key-store corruption issue under concurrent access.
| Prop | Type | Description |
|---|---|---|
| releases | ChangelogRelease[] | { version, date, summary?, entries, yanked? } |
| title | string | Heading |
| subscribeHref | string | RSS or notification link |
Entry types follow Keep a Changelog: added, changed, fixed, deprecated, removed, and security. The last two are the ones most hand-written changelogs drop, and they are the two a consumer most needs.
security deserves its own type rather than living inside fixed, because a reader triaging an upgrade filters for it specifically — and burying a CVE fix among bug fixes is how patches go unapplied. deprecated is the early warning that lets someone migrate on their schedule instead of discovering a removal in a release that breaks their build.
The breaking filter is a separate axis from type. A change can be changed and breaking, or removed and routine; treating "breaking" as its own dimension is what makes "show me only what I have to act on" a single click.
yanked marks a withdrawn release. Deleting a bad release from the changelog is the wrong instinct — someone is running it, and they need to see that it was pulled and what to move to. The demo keeps 3.3.2 visible and labelled for exactly that reason.
New components every week
Get the week's new Kelvin UI components and templates in one short email. No spam, unsubscribe anytime.