Move off the release train to a simpler release model

[NullVoxPopuli-ai-agent]

Ember's "release train" today bundles two separate things: a six-week release cadence, and a multi-channel promotion pipeline (canary → beta → release branches, cut and promoted by a rotating release manager working a manual checklist each cycle).

This RFC keeps the cadence and replaces the pipeline. The six-week beat is the part that works and stays exactly as it is; what goes away is the multi-branch channel machinery and the hand-run ceremony.

The shape:

• A single long-lived branch, main — no canary/beta/release branches, none of the cherry-pick/back-merge bookkeeping.
• Stable is cut from main by release-plan on the same six-week schedule. The npm publish runs inside a job bound to a protected GitHub deployment environment — a required reviewer approves the deployment; that single click is the entire residual ceremony (no manual version bump, changelog, or npm publish).
• Prerelease collapses to a single @alpha, auto-published from main the way Embroider published its prereleases. Since ember-source lives in git, main also stays directly consumable as a git ref (exactly how canary is consumed today). @beta goes away; its consumers move to @alpha.

Explicitly unchanged: SemVer, the six-week cadence, the deprecation policy, LTS, and the major-version process of RFC emberjs#830. Across a cycle release-plan collapses labeled PRs into a single bump (highest impact wins → one minor per six weeks, as today), and because RFC emberjs#830's M.10 freeze already controls when a breaking change may merge, a label-driven major bump only ever lands in the major window — not mid-cycle.

The RFC also covers lockstep across ember-source/ember-cli/WarpDrive, drawbacks (the @beta → @alpha migration for ember-try/addon CI, the lost soak stage, labeling discipline, concentrated publish authority, release-plan dependency), alternatives (status quo, keeping @beta as a second prerelease stream, changesets, fully continuous releases), and unresolved questions (@alpha cadence, lockstep, approver group).

Rendered: text/0000-move-off-the-release-train-to-simpler-release-model.md

🤖 Generated with Claude Code

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[NullVoxPopuli-ai-agent]

Addressed all inline comments in ad52c78 and resolved each thread. Summary:

• "there's never been a canary branch" (×2) — removed all canary-branch framing. The promotion pipeline is now described as the default branch → beta/release branches; canary is no longer called a branch anywhere.
• "embroider and glint used to publish their pre-releases" — reworded to "the way Embroider and Glint used to publish their prereleases."
• "remove this statement" (the "main lives in git / git ref" line) — removed from the Summary.
• "and the time it takes maintainers with limited time" — folded into the Motivation intro.
• "no formal release manager… Katie / Chris… any maintainer can trivially release" — rewrote that section: no RM rotation, it's effectively one person per project, and the headline benefit is that release-plan lets any maintainer release (review preview PR + approve deployment, no npm keys).
• "don't mention ember-data" — removed ember-data everywhere (motivation, lockstep, unresolved questions).
• "don't use 'hand-publish', we publish from CI" — removed; the cost is now framed as maintainer time / process, not the publish mechanism.
• "emphasize this + mention release-plan handles it" — version/changelog point is now its own emphasized section saying release-plan does it for us.
• "remove this section" (canary-duplicates-the-git-repo) — deleted.
• "don't add subheadings to headings" — stripped the em-dash/colon taglines from headings (Keep the cadence, Releasing, Deprecations, majors, and LTS).
• "release-plan… one way, label-driven, don't add fluff" — rewrote the metadata section to the actual labels (breaking/enhancement/bug/documentation/internal) with changelog from PR titles; dropped the changeset alternative.
• "this is not manual… label a PR on the 12×6-week cadence" — majors are now described as label-driven (breaking) landing on RFC RFC: Evolving Ember's Major Version Process emberjs/rfcs#830's ~12×6-week cadence, with no manual version work.