accepted

v0.2 is pre-release: break contracts outright, no deprecation shims

Until v1, Campos removes deprecated APIs in the same commit that introduces their replacement. No `@deprecated` markers, no opt-in migration windows, no shim layers. Consumer migration is part of the same packet.

policybreaking-changeversioning

Context

Chart APIs are still evolving rapidly — the recent chart-reference-layers packet alone removed three exported types (LineChartEventInput, LineChartEventModel, LineChartEventStyle) and one prop (events). Supporting deprecation shims multiplies surface area and delays the point at which the API feels coherent enough to freeze.

Decision

In pre-release v0.2.x:

  • Remove deprecated APIs in the same commit as their replacement.
  • No @deprecated JSDoc markers, no runtime console warnings about upcoming removals, no re-exports of old names pointing to new names.
  • Consumer migration (in apps/site, tests, etc.) lands in the same PR.
  • Golden SVG fixtures regenerated when rendered output shifts.

The absence of a deprecation path is itself the signal that the API is moving alpha — consumers should not be pinning against it.

Consequences

  • Larger atomic commits. The axis-gutter sweep touched 23 files in one commit; the chart-reference-layers migration touched ~30.
  • Pre-commit hooks must pass end-to-end in one change — no “migrate consumers in the next PR” dodge.
  • External consumers outside this monorepo (none today) would feel hard breaks on every minor release. Acceptable while no external consumers depend on stability.
  • Trade reverses at v1: once a stability target is declared, the deprecation cycle becomes mandatory.

When this changes

Revisit when a deliberate v1 freeze target is set. At that point, the policy inverts: deprecate first, remove one minor version later.

← All decisions