From ebf657d2871794f47fb9217d20de450bb0e7f30f Mon Sep 17 00:00:00 2001 From: Chris Manson Date: Sat, 31 Jan 2026 10:58:03 +0000 Subject: [PATCH] add notes for tooling team 27th Jan --- st-embroider/2024/2026-01-27.md | 59 +++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 st-embroider/2024/2026-01-27.md diff --git a/st-embroider/2024/2026-01-27.md b/st-embroider/2024/2026-01-27.md new file mode 100644 index 0000000..46b67d4 --- /dev/null +++ b/st-embroider/2024/2026-01-27.md @@ -0,0 +1,59 @@ +# YYYY-MM-DD + +Note Taker: +Time Keeper: + +## Attendees + +Add yourself to the list if you attend and check the box! + +- [x] Ed Faulkner (EF) +- [x] Chris Manson (CM) +- [x] Alex (A) +- [x] Preston Sego (PS) +- [x] Simon Ihmig (SI) +- [x] Katie Gengler (KG) +- [ ] Krystan HuffMenne (KH) +- [x] Peter Wagenet (PW) +- [ ] James Davis (JD) +- [x] Liam Potter (LP) +- [x] tommyjr + +## Topics + +### Ember 7 pre-planning: deprecation removals (not covered by the auto throw e.g. AMD bundles and barrel file), breaking bugfixes (flipping default values in Ember ENV), etc. <@mansona> + +- Ones that we know of + - Making sure we don't publish AMD bundles + - Making sure we don't publish the barrel file +- it's great that we have the throw on deprecation functionality but we should endevour to remove as much as possible +- flipping default values in Ember ENV + - this should have been done at an earlier major +- KG: can we break the `ember-testing` package + - we only soft deprecated it + - I can't make it work on a modern ember + - CM: can we clarify what you are talking about - because we have it in the new bluerpint + - KG: it has some side-effects but there are some other helpers (that aren't moved to `@ember/test-helpers`) + - we contemplated adding a deprecation and backporting it + - EF: we need to make sure that the last few things that are used in `@ember/test-helpers` are structured well + +#### The classic app blueprint was not updated to use warpdrive when the Vite one was. What is our policy here? Do we need to do a release backport? (seems risky) Should we do a beta backport? Should we (as a team) make sure that we don’t merge large structural changes to the vite blueprint without there also being one for the classic? <@mansona> + +- (explanation of the situation) +- EF: do we expect it to work - yes +- CM: do we do a backport a "fix" to the release +- EF: i agree the this is a policy question - it would have been better if we did this at the same time +- we could decide to just fix it with the release pipeline +- CM: but that would mean the cognitive disonance would exist for 2 minors +- (discussion about deprecations) +- CM: I want to deprecate the old blueprint (and potentially the old build) during the 7.x cycle +- EF: then keeping the new blueprint and the classic one up to date helpes people cross the gap +- CM: then we don't need it to be backported to release - but we can backport to beta if we want to + + +### isBinaryFile situation - do we downgrade? Maybe we vendor the code? https://github.com/gjtorikian/isBinaryFile/pull/102 <@mansona> + +- EF: this response from the maintainer doens't instill confidence +- CM: 🫠 +- EF: why are we even using this dependency? +- CM: we can just downgrade the package