Propose moving to release-plan and off the release train#1198
Open
NullVoxPopuli wants to merge 3 commits into
Open
Propose moving to release-plan and off the release train#1198NullVoxPopuli wants to merge 3 commits into
NullVoxPopuli wants to merge 3 commits into
Conversation
* Add RFC: move off the release train to a simpler release model Propose retiring Ember's calendar-driven release train (fixed six-week minor cadence, rotating release-manager ceremony, hand-maintained canary/beta/release channels) in favor of an automated, PR-driven model powered by release-plan. Work integrates on `develop`; every merge can release from `main`, with the npm publish gated behind a protected GitHub deployment environment requiring manual approval. Stable releases go through the same gated release-plan publish. SemVer and existing compatibility guarantees are unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Drop the develop branch; release from a single `main` PRs merge to `main`, canary builds come off `main`, and the gated release-plan publish runs from `main`. Removes the develop/main split and the "promote develop to main" framing throughout. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Keep the six-week cadence; drop only the canary/beta channels Reframe: the proposal retains the six-week release schedule and SemVer/ deprecation/major (RFC 830)/LTS policies unchanged. What changes is the branch-and-channel machinery — a single `main`, stable cut from it via release-plan on the existing cadence (gated by a GitHub deployment env), and the published canary/beta channels removed in favor of tracking `main` via git. Updates motivation, channels, deprecation/major/LTS, drawbacks, alternatives, and unresolved questions accordingly. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Correct canary/beta channel facts; alpha auto-published from main Canary is consumed from git, not an ember-source@canary npm dist-tag; only @beta is a published prerelease tag today. Reframe the prerelease story: publish an `@alpha` dist-tag automatically from `main` (like Embroider's prereleases) while keeping main's git-ref workflow, drop the `@beta` tag, and resolve the former "build artifact consumption" open question. Updates motivation, channels, teaching, drawbacks, alternatives, and unresolved questions to match. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Holistic pass: reconcile cadence with release-plan and RFC 830 Close the gaps the incremental edits left: - Explain that release-plan collapses a cycle's labeled PRs into a single bump (highest impact wins -> one minor per six weeks, as today), and how the continuous @Alpha relates to the scheduled stable snapshot. - Reconcile majors with RFC 830: the M.10 freeze already gates when a breaking change may merge, so a label-driven major bump only happens in the major window -- not mid-cycle. - Clarify the scheduled cut is triggered by a maintainer or scheduled workflow; note ember-data is now WarpDrive. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Address review: no canary branch, accurate release-plan, drop ember-data Incorporate all inline review feedback: - canary was never a branch; remove canary-branch framing everywhere and the duplicate-the-git-repo section - release-plan is label-driven (breaking/enhancement/bug/documentation/ internal); changelog comes from PR titles; remove changeset "fluff" - we publish from CI already (no "hand-publish"); the cost is maintainer time and bus-factor (Katie/Chris), and release-plan lets any maintainer release - emphasize release-plan handles version+changelog for us - majors aren't manual: breaking label + RFC 830's 12x6-week cadence - drop ember-data mentions; strip em-dash/colon taglines from headings - remove the "main lives in git" statement from the summary Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Reflow: one line per paragraph and list item, no hard wrapping Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Resolve open decisions: nightly @Alpha, drop beta, timing-lockstep, maintainer cut, informal approvers - @Alpha publishes nightly from main (not every merge) - beta fully dropped; the keep-beta option is now an alternative, not a TBD - lockstep is timing-based: ember-source/ember-cli release independently on the same six-week date, with no cross-repo coordination - the six-week stable cut is a maintainer merging the release-preview PR - publish approvers are the same active people who release today (informal) - prune the now-decided unresolved questions Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Clarify canary is unchanged; alpha scheme is release-plan default; beta cleanup is removal - canary stays exactly as today (main consumed from git); add it explicitly to the channels list and stop implying alpha replaces it - @Alpha is a new published npm prerelease of main; release-plan handles the version scheme, nothing special - ember-try/beta consumers remove their @beta scenarios (canary unaffected) - Unresolved questions: none outstanding; only implementation remains Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Unresolved questions: n/a Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Rewrite in NullVoxPopuli's RFC voice; remove all em-dashes Conversational tone (today/folks, underscore emphasis, parentheticals), no em-dashes, lighter bold lead-ins. Content unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Drop the status-quo alternative Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Alternatives: drop keep-beta and changesets options Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Address PR review: trim drawbacks, drop Steering, keep LTS backports - remove redundant 'long-lived branch' phrasing; main is always that - just state release-plan's labels, no preamble - drop the soak-stage, labeling-discipline, publish-authority, and tooling-dependency drawbacks (non-issues / we own release-plan) - remove the Steering bullet and the steering team; steering doesn't decide this - scope removed backporting to the beta/release branches; keep LTS backports when needed - note consumers won't notice a difference Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Don't frame the cadence as in question; state the cost directly Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * Apply suggestion from @NullVoxPopuli * Apply suggestion from @NullVoxPopuli * Apply suggestion from @NullVoxPopuli * Tone down marketing language Drop superlatives and sales phrasing (biggest win, trivially, turnkey, well loved, the important bit, everyone else already trusts, from anywhere, tribal knowledge) in favor of plain description. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: NullVoxPopuli <199018+NullVoxPopuli@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
NullVoxPopuli
commented
Jun 6, 2026
kategengler
reviewed
Jun 7, 2026
|
|
||
| ### Releases depend on too few people | ||
|
|
||
| We don't actually have a formal release-manager rotation. In practice the release comes down to essentially one person per project: @katiegengler for `ember.js`, @mansona for `ember-cli`. This is a bus-factor and burnout risk -- which other teams have already faced. When that person isn't around (due to life, unplanned things, etc (this alone is not a big deal)), the release slips. |
Member
There was a problem hiding this comment.
I think it is important to note the ember-cli current does use release-plan
Contributor
Author
There was a problem hiding this comment.
Oh do you happen to know how i get confused? Lol. Is something ember-cli using release-plan?
Member
There was a problem hiding this comment.
Huh? ember-cli is using release-plan to release...
Contributor
Author
There was a problem hiding this comment.
what is "ember-cli current"?
kategengler
reviewed
Jun 7, 2026
|
|
||
| ### release-plan automates the mechanical work | ||
|
|
||
| Working out the next version number and assembling the changelog are mechanical, error-prone steps that shouldn't be done by hand. release-plan does this for us, deterministically, from the labels and titles of the PRs that got merged. The ecosystem has already standardized on release-plan for almost every addon, so the framework doesn't need a bespoke process that's more work than the tooling everyone else uses. |
Member
There was a problem hiding this comment.
My feeling is that that release-plan has made things more complicated on ember-cli. I have an issue somewhere on ember.js that explains various things that need solutions before we can move to release-plan.
I don't feel any of the current release process is error-prone and it is well documented. I wouldn't mind more of it being automated but the most manual step right now is translating the CHANGELOG from a list of everything to a list of things for users to actually care about.
Contributor
Author
There was a problem hiding this comment.
yeah the way ember-cli is using release-plan for trains is not how anyone should be using release plan.
part of the problem is how backporting and forward porting between the train tracks -- which is exactly what I don't want us doing via this proposal, as it's too complicated.
Something I should add to this RFC is that backports and such should use the ember-source model of updating for things like LTSes (which I think is the only set of targets we'd backport things to?)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Propose moving to release plan and off the release train
Rendered
Summary
This pull request is proposing a new RFC.
To succeed, it will need to pass into the Exploring Stage, followed by the Accepted Stage.
A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.
An FCP is required before merging this PR to advance to Accepted.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.
Exploring Stage Description
This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.
An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an
Exploringlabel applied.An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.
Accepted Stage Description
To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.
If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.
When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.
Checklist to move to Exploring
S-Proposedis removed from the PR and the labelS-Exploringis added.Checklist to move to Accepted
Final Comment Periodlabel has been added to start the FCP