New language features are proposed to TC39, the Ecma International committee that maintains ECMA-262. A champion (a committee delegate) owns each proposal and advances it by presenting it at a TC39 meeting, where the committee reaches consensus before every stage change.
| Stage | Meaning | Entry bar |
|---|---|---|
| 0 | Ideation | None; authors assign it themselves |
| 1 | Designing a solution | Champion, written problem and solution shape, public repo |
| 2 | Refining the solution | Preferred solution chosen, draft spec text (placeholders allowed) |
| 2.7 | Testing and validation | Complete spec text, reviewers and editors signed off |
| 3 | Implementation and feedback | Sufficient testing and pre-implementation experience |
| 4 | Finished | Two compatible implementations pass test262, real shipping experience, editor approval |
Stage 2.7 is the newer step: the design is frozen apart from changes found through testing, and tests are written. Stage 3 is where engines implement and ship, so feedback can still change or even stall a proposal.
A Stage 4 proposal is merged into the spec draft. The yearly edition is branched from the draft at the March TC39 meeting; from then on only editorial changes are accepted, and the Ecma General Assembly approves it in June (every edition since 2011 is dated June, although the process document still says July). Anything that reaches Stage 4 later waits for the next edition.
When is a feature safe to use? Stage 4 means the spec is settled and two engines already pass the tests, but your users' browsers matter more than the stage. Check actual support (MDN compatibility data, caniuse) and your target environments. Stage 3 is for experiments or build-time tooling that you control.