lukk

Appearance

Upgrading ​

Both halves of lukk are pre-1.0 (0.x). Per SemVer §4, a minor bump (0.x.0) may carry a breaking change; a patch bump (0.x.y) never does. The 1.0 releases will mark API/schema stability and end this cadence.

Each repo keeps a version-specific UPGRADE.md — the authoritative, "you may need to do something" subset of its changelog, organized highest-version-first with High / Medium / Low impact tags. Read it (and the changelog) before bumping:

Ground rules ​

  • Pin an exact version. Don't float ^ on a 0.x dependency you can't retest.
  • Upgrade the server first. lukk's HTTP contract is the source of truth; the client only speaks it. When a server change needs a matching client change, its UPGRADE.md entry says so.
  • Nothing auto-applies. lukk's migrations are publish-only and its behavior is config-gated — an upgrade only touches what you've opted into.
  • Run your tests after bumping, then read the entries at or below your target version.

Highest-impact change right now ​

WARNING

lukk 0.4.0 adds a guard column to refresh_tokens (for multiple guards). It's folded into the core migration, so fresh installs and single-guard apps need no action. Only a pre-release install that already ran the old migration must add the column by hand — see lukk UPGRADE.md.

lukk-js has shipped no breaking changes yet — every release has been additive.