All field notes

Release5 min read

What Coordiation 1.0 stable still needs from us

A release candidate can be feature-complete without being ready for the stable channel. Promotion should follow evidence, not momentum.

01

Release candidates are for proving the boundary

The first coordinated release candidate brings the compiler, integrations, registries, editor tooling, design assets, and AI lifecycle into one versioned train. That proves the intended shape, not every production environment.

The next channel lets real projects test the boundary while the latest channel remains stable and unsurprising.

02

Stable means repeatable across environments

Before promotion, declared Linux, macOS, and Windows workflows must pass on supported Node versions. Native artifacts must be signed and verified. Clean installs must import every public entry point. Registries, tarballs, documentation, and production endpoints must agree.

  • No open release-blocking feedback.
  • Current migration and compatibility evidence.
  • Accessible and responsive component/theme checks.
  • Explicit maintainer approval for the npm latest tag.
03

Feature count is not release evidence

A framework can contain hundreds of utilities and still fail a clean install. A theme can look complete and still trap keyboard users. A package can pass local tests and still ship the wrong files.

Stable is the moment the declared contract has been demonstrated repeatedly enough to become the default. Until then, the honest label is release candidate.