v2.0 release checklist about glimmer.js HOT 4 OPEN

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.

from glimmer.js.

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.)

from glimmer.js.

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).

from glimmer.js.

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.

from glimmer.js.