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.
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.
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.
