-
Notifications
You must be signed in to change notification settings - Fork 75
fix ci #379
fix ci #379
Conversation
Would this close #230 ? |
partially -- I think deciding on a policy should still happen. I'm in favor of mirroring ember's support here |
fa1a606
to
5aae2cc
Compare
.github/workflows/ci.yml
Outdated
@@ -51,7 +51,7 @@ jobs: | |||
|
|||
strategy: | |||
matrix: | |||
ember-version: [default, release, beta, canary, lts-3.12, lts-3.16] | |||
ember-version: [default, release, beta, canary, lts-3.28, lts-3.24] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was dropping support tied to the requirements for the @cached
decorator, or is it just because/part of the blueprint update? (i.e. are we able to keep the older Ember versions if we wanted to?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can give it a go -- I was mainly going with the ember support policy, cause I don't know what the glimmer one is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i guess it's fine 🙃
(assuming we trust the tests)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I wasn't implying that we should do it one way or the other, just wanted to know if it was deliberate/required or out of convince (what could be fine). Although, now that you proved that it works (at least according to the tests), if it doesn't end up hurting anything, I personally would be inclined to keep the support to aid adoption (though we should also include 3.20 in the matrix in that case).
However, I do think it is important to double check and make sure we in fact could support the @cached
decorator on all of these versions, at least before we release 2.0 final.
@@ -0,0 +1,5 @@ | |||
{ | |||
"application-template-wrapper": false, | |||
"jquery-integration": false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't have the async observer stuff, intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It turns out that I had an extra optional-features file.
This file, the traditional location, is the only place where the test runner looks for these options, afaict. I've moved the more complete optional-features.json to this location so that it's proper octane (including async observers)
@@ -1 +1 @@ | |||
// Minimum TypeScript Version: 3.1 | |||
// Minimum TypeScript Version: 4.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normally I think there are some consequences with this, but given that we apparently need to release a major version bump anyway, this is probably fine. Though @chriskrycho should probably confirm just in case. (I am not sure how much of the @glimmer/*
types ended up being consumed directly, as opposed to being replaced/superseded by the Glint wrappers anyway.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is indeed breaking! And at this point the majority of the ecosystem is not using Glint, in past because addons cannot do so. (That’s one of the big motivations for moving the Signature RFC forward.) If this is intending to target a 2.0 release, the breaking change is fine. Otherwise we should leave it at its previous value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have to do a breaking change anyway without doing an enormous (imo) amount of work to support from ember 3.12 to current (macros, no more partials, etc)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems fine, then, with two caveats:
- I believe there are a number of other changes already queued up for a v2, so we need to evaluate those as part of this work.
- We need to make sure that end users can actually successfully have both v1 and v2 active in an app's codebase, since it will take some time to migrate the ecosystem.
Two additional considerations:
- We can support the Glint Signature changes without a breaking change, but it would be much easier to not. We need to decide on what to do with that.
- There are other changes we want to make to align the Glimmer.js API with the version of the Glimmer component API available in Ember.js, specifically around lifecycle hooks. I am not sure if those have yet landed, but we need to follow up and evaluate those before we actually publish the v2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what specific things do we need to do to move forward?
(I'm not clear on what next steps are)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the most part, I don't think should affect this PR, considering we already released 17 (!) betas for 2.0.0. But those are probably checklist items for the 2.0.0 final.
Hmm, actually this might be a good enough reason to drop < 3.24, or else we probably need to do some Embroider macro things to make it work. But in any case, I am confused why the tests are passing? |
Thanks for putting this together and providing the context for the changes, they are super helpful! |
…tually work, considering the destroyable apis weren't added until 3.22
I've re-dropped 3.12 and 3.16. I think the destroyable stuff was added in 3.22, and I don't trust the test suite with ember-source < 3.22 |
Seems like we will need a checklist for the 2.0 release outside of this PR (and one of the items should be landing the Separately, I am pretty concerned that the test were passing with 3.12/3.16 in the matrix since there is no destroyable APIs. @NullVoxPopuli can you investigate what's up, or at least open an issue? Are we just missing some test coverage around destruction, or were the tests running at all? In any case both of those things are not directly related to this PR, I think we are good to proceed. Also wouldn't mind if @rwjblue could give this a look when he is back to see if I missed anything around the upgrades. Thanks again @NullVoxPopuli for taking care of this! |
Thanks! <3 Issue here (for now, I gotta pivot to some embroider work for the near near term) |
Thanks for suggesting that, @chancancode – I just opened #383 to that end! |
Most of the diff is from the yarn.lock file
The commits show a progression of why or what changed if you like reviewing that way. I'm also happy to squash if that's what folks would like.
Summary
@glimmer/component
's dependencies to be compatible with the newer ember versionsember-auto-import@v2
is required for ember 4+@glimmer/component
(for the specified ember-source in that package.json) -- most of the diff is from these sorts of changes@glimmer/vm
(and related dependencies)ember-component-manager
changed from using Ember global apis to@ember/destroyable
https://github.com/glimmerjs/glimmer.js/pull/379/files#diff-f17a36b7758421e673e4dae6c85e48d2a576da5bf873a4582ea563bcd2e5d742
Points of Interest
What this PR Unblocks