v2.0 release checklist

[chriskrycho]

To my knowledge, this is the list of things we need to do before cutting the v2 release (with folks named as being the closest/most knowledgeable on the questions, not assigning them).

Hard blockers

As long as we solve these, I believe all the others listed as Soft Blockers could actually be punted by shipping what we have as v2 with a not-that-long-from-now v3 to follow.

• design and implement compatibility story so the ecosystem can have a story where apps and addons' direct and transitive dependencies can include both v1 and v2 versions of this, so that we do not end up having to do a "big bang" migration across the whole ecosystem (@rwjblue)
• address Embroider compatibility in the build for the v2 addon; related to the previous point this may mean tweaking the v1 build as well somehow? (@ef4, @rwjblue)

Soft blockers

• decide whether the result of RFC: Glimmer component Signature type emberjs/rfcs#748 should be blocking for v2 (likely we need to support the new API in both the v1 and v2 branches, but it'd be nice to not have to support the old API in the v1 branch so that at some point we can drop support for the old signature as the ecosystem moves to v2 (@chriskrycho)
• finalize design decisions for v2 public API (removal of willDestroy etc.) (???)
• support <template> as the authoring format, assuming First-Class Component Templates emberjs/rfcs#779 is merged ~a week from now (@chriskrycho)
  • we should also decide what that means for existing users of the hbs design: do we deprecate it in the next beta and then switch over in the release? do we deprecate it but support both for v2? etc. (@chadhietala, @chiragpat)

There may be others I've missed; please list them below and I'll add them.

[ef4]

On the topic of ecosystem compatibility, the thing I'd like to stress it that it's an accident of history that @glimmer/component ships as a standalone package while @ember/helper, @ember/routing, etc don't.

"How do we do a semver major release of @glimmer/component?" should have the exact same answer as how we do a semver major release of @ember/helper.

We don't support having two semver-incompatible imlementations of @ember/helper in the build, and I don't think that we should. For the same reason, I don't think we should support having two semver-incompatible versions of @glimmer/component in the build.

We want addons to be able to have a single-dimensional test matrix: what ember versions do you support? Not, what factorial combination of ember packages do you support.

[chriskrycho]

While I broadly agree with that goal, I think there are three key bits here from my POV:

1. Having the ability to do this when needed from a technical POV does not mean we must do it regularly from a cultural POV. It just means that we have the flexibility to do it on rare occasions when there is good reason to.

2. As an addon author, I don’t think having the technical capability here would change your support matrix if we get the interop story correct. You just say “I support Ember v4.4–4.8” (where 4.4 was the version which introduced support for Glimmer Component v2, which you happen to be using), and you don’t really care whether other folks are using other things.

3. We haven’t resolved that discrepancy between the Ember and Glimmer versioning pattern for the @glimmer/* libraries yet, and AFAICT there is no way to do so during the Ember 4.x era while also addressing the other issues here?

Either we need to make v1 work with all the pieces identified above with no breaking changes, or we need to support having both v1 and v2 in the ecosystem in some way. If we can do the former, that’s excellent but it’s also news to me based on previous conversations! (Technically, continuing to ship the v1 here is a pretty significant smell to me from the TS angle, since it provides types to Ember consumers which are wrong, and in a way that we more or less cannot fix, because the Glimmer.js @glimmer/component API is a superset of the Ember.js @glimmer/component API.)

[ef4]

Either we need to make v1 work with all the pieces identified above with no breaking changes

But I think that's already true. The API changes in @glimmer/component 2 only apply to users of glimmerX, they're non-breaking for Ember users.

And if we make @glimmer/component 2 require ember >= 4, then it's not even a breaking change for it to become a v2 addon, because ember 4 itself requires that you have v2 addon support (by having ember-auto-import >=2).

[chriskrycho]

That's good! We may be talking about different angles here; I'm not sure. 🤔

The thing I'm pointing at is the question of whether we have to go walk the entire addon ecosystem leaves-in to update each addon to use the v2 of this before anything which consumes it to in turn do the same, or whether we can have a situation where addon A can be using Glimmer Component v1 itself, while also consuming addon B which is using Glimmer Component v2.

If that's what we end up deciding we need to do, it's just going to be an enormous lift which gates any large app on doing the work for all of its dependencies, vs. being able to have a more progressive migration with both living side-by-side for some time.