Propose moving blueprints off of the release train #1160

NullVoxPopuli · 2026-01-05T22:44:15Z

Propose moving blueprints off of 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 Exploring label 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

The team believes the concepts described in the RFC should be pursued.
The label S-Proposed is removed from the PR and the label S-Exploring is added.
The Ember team is willing to work on the proposal to get it to Accepted

Checklist to move to Accepted

This PR has had the Final Comment Period label has been added to start the FCP
The RFC is announced in #news-and-announcements in the Ember Discord.
The RFC has complete prose, is well-specified and ready for implementation.
- All sections of the RFC are filled out.
- Any unanswered questions are outlined and expected to be answered before Ready for Release.
- "How we teach this?" is sufficiently filled out.
The RFC has a champion within one of the relevant teams.
The RFC has consensus after the FCP period.

void-mAlex · 2026-01-05T22:57:15Z

text/1160-no-more-release-train.md

+
+However, default blueprints (what `ember new` / `ember addon` generate) have different ergonomics than framework runtime code:
+
+- Blueprint changes primarily affect *newly generated* projects, not existing ones.


I find this highly questionable as ember-cli-update will run ember new as part of an upgrade of an existing project
I don't want that to suddenly be the latest version

ember-cli-update runs on ember-cli's output, not the direct output of a blueprint, so this workflow is unchanged

correct me if I'm wrong but it 100% does ember new under the hood for you, which this rfc proposes changes what it would do

The only change is that IF we need to update old versions, we would need to update ember-cli, and then there is no issue with ecu

void-mAlex · 2026-01-05T23:00:28Z

text/1160-no-more-release-train.md

+However, default blueprints (what `ember new` / `ember addon` generate) have different ergonomics than framework runtime code:
+
+- Blueprint changes primarily affect *newly generated* projects, not existing ones.
+- The common social workflow is to propose blueprint improvements via PRs to the default branch.


this suggests to me that you cannot fix/patch previous bp version, what happens when the bp tries to use a nodejs feature that doesn't exist on all supported version of the bp it's trying to generate

we release a new ember-cli with the fix in the rare case where that would happen

void-mAlex · 2026-01-05T23:02:10Z

text/1160-no-more-release-train.md

+
+Additionally, while blueprints have historically been used as part of Ember’s upgrade and migration story, that can have an unintended cost for *new* users: improvements that primarily exist to support long-lived apps and slower-moving upgrade paths can accumulate in the defaults. This can leave new users feeling like they are “paying” for technical debt created by projects that cannot keep up, and that the defaults are holding them back.
+
+We can also think of official blueprints as a *product*: they are the first experience many users have with Ember, and they encode decisions about tooling, project layout, and “pit of success” defaults. Like any product, we want customers to receive fixes and refinements as quickly as possible.


not at the cost of stability

that's not a cost -- not something we're trading away with this proposal

it's too big of a tradeaway for me

I'm just saying we don't give up any stability

void-mAlex · 2026-01-05T23:06:33Z

text/1160-no-more-release-train.md

+
+Each `ember-cli` release must pin to an *exact* blueprint version for each blueprint package it uses.
+
+In practice, this means the `ember-cli` `package.json` uses exact versions (e.g. `"1.2.3"`, not `"^1.2.3"` or `"~1.2.3"`) for blueprint dependencies.


this makes things worse by cutting off ability for us to release fixes for ember-cli

all we have to do is release ember-cli for the fixes

but nobody will see them since they are pinned to exact version

If they aren't updating ember-cli, why would they update their blueprint?

ember-cli is already nearly pinned, as it uses ~ on the blueprint versions

void-mAlex · 2026-01-05T23:08:01Z

text/1160-no-more-release-train.md

+
+- Blueprint changes primarily affect *newly generated* projects, not existing ones.
+- The common social workflow is to propose blueprint improvements via PRs to the default branch.
+- When blueprint improvements are tied to a release train, users can wait weeks (or longer) to see improvements in newly generated apps and addons.


general feeling already is that things are moving too fast in the js ecosystem and nobody is able to keep up, waiting ~6 weeks is not a bad thing

I don't think anything is moving too fast in our ecosystem.

void-mAlex · 2026-01-05T23:09:17Z

text/1160-no-more-release-train.md

+When a user runs `ember new` or `ember addon`, `ember-cli` must:
+
+1. Determine the bundled blueprint version (from its pinned dependency).
+2. Check the registry for the latest blueprint version.


there are plenty of restricted systems that don't allow network access or would rely on internal mirrors that have been vetted

that's fine -- they wouldn't be prompted

Move blueprints off of the release train

73461af

github-actions bot added the S-Proposed In the Proposed Stage label Jan 5, 2026

Updates

9b7b4e9

void-mAlex reviewed Jan 5, 2026

View reviewed changes


		However, default blueprints (what `ember new` / `ember addon` generate) have different ergonomics than framework runtime code:

		- Blueprint changes primarily affect newly generated projects, not existing ones.


		Additionally, while blueprints have historically been used as part of Ember’s upgrade and migration story, that can have an unintended cost for new users: improvements that primarily exist to support long-lived apps and slower-moving upgrade paths can accumulate in the defaults. This can leave new users feeling like they are “paying” for technical debt created by projects that cannot keep up, and that the defaults are holding them back.

		We can also think of official blueprints as a product: they are the first experience many users have with Ember, and they encode decisions about tooling, project layout, and “pit of success” defaults. Like any product, we want customers to receive fixes and refinements as quickly as possible.


		Each `ember-cli` release must pin to an exact blueprint version for each blueprint package it uses.

		In practice, this means the `ember-cli` `package.json` uses exact versions (e.g. `"1.2.3"`, not `"^1.2.3"` or `"~1.2.3"`) for blueprint dependencies.

Uh oh!

Propose moving blueprints off of the release train #1160

Are you sure you want to change the base?

Propose moving blueprints off of the release train #1160

Conversation

NullVoxPopuli commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Propose moving blueprints off of the release train

Summary

Checklist to move to Exploring

Checklist to move to Accepted

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

NullVoxPopuli Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

NullVoxPopuli commented Jan 5, 2026 •

edited

Loading

NullVoxPopuli Jan 5, 2026 •

edited

Loading