Skip to main content
Kanso UI is below 1.0, so a minor release can break a call site. Every breaking change on the way to 1.0 is listed, with the edit each one asks for, in UPGRADING.md in the repository. That file is the one place it is kept, since each breaking pull request adds its line there.
1

Find the version you are on

2

Read UPGRADING.md from the next version down

Find your version in UPGRADING.md and work down from the first section after it. Everything above it already applies to you.
3

Check the removed custom properties

A --kui-* override for a property that no longer exists raises no error at all; it simply stops applying. They have a section of their own, and are the easiest change to miss.
4

Check the behaviour changes

Some changes compile fine but change what a reader sees or hears. They matter to a test that queries by name or by text.

Pinning the version

Pin the package exactly, 1.2.3 rather than ^1.2.3, so a minor that renames a prop reaches you as a pull request you can read rather than a broken install. Renovate or Dependabot then opens each bump. The conventions explain why every kanso-labs repository pins this way.

Release notes

Each release’s notes are on GitHub Releases. From now on, a breaking release names its migration in the changelog entry itself.