Feanil Patel ticket enabling cron CI of master every week so we know when external changes might have broken some repos that are usually not getting updates.
we know that we’ll have these slots, and we know we want to DEPR the old way of doing things. when do we announce the breaking change?
Maybe just wait until OEP-65, post-sumac
sounds like we’re signing up to keep the old way working for a bit until the new way has landed
brian would prefer depr’ing forking the footer sooner than later. we have the footer slot, can we push people towards that now? it would get people on the right path.
decision: will DEPR forking the header and footer
sumac will support it, it’ll be unsupported in teak
also an ongoing conversation on doing frontend plugins better – eg, plugins owning the configuraiton rather than env.config.js owning it. See frontend-wg notes for more info.
Adolfo: What warning/approval is needed from 2U in order to merge these upgrade PRs?
Feanil: This first step is to just add Node 20 support, since that is additive, we shouldn’t need 2U’s approval
tutor will switch to node 20 once support is added
nvmrc won’t be switched to node 20 until we are ready to drop node 18 support
Adolfo: We should start by having the Node 18 vs 20 test matrix, making Node 20 optional at first, so you know which repos have Node 20 working. Then get Node 20 working, then drop Node 18 support.
Brian S: What to have in nvmrc? Use whatever you want package-lock.json to be ge
In the odd edge case where we can’t have both versions running at the same time, then it’ll be different. we expect this on a few MFEs.
Robert: just clarifying, the backwards incompat step is the change the package-lock.json?
yes
More precisely, this is the breaking change:
nvmrc: 18->20
package-lock.json: generate with 20
drop Node 18 tests
We need to be Node 20 compatible by Sumac. We will remain Node 18 compatible for Sumac wherever possible. In Dec/Jan, at the 6-month depr acceptance mark, that’s when we drop Node 18 support
Awais is working through these, and at least one community member has stepped up to help. If you are interested please feel free to jump in with implementation or review.
Robert: will there be backwards incompat changes? even minor ones like a 401 becoming a 403?
Feanil: for this first conversion, based on the unit tests, the APi stayed the same
Feanil: If/when an API endpoint is broken by converting to DRF, we’ll need to use the DEPR process
Testing for regressions?
Awais has been manually testing, including error codes. Has not changed existing unit tests.
Awais will check headers going forward
Feanil: Write test steps down in PR
Parallelization
Awais will help that one volunteer so far
After a few more PRs we can probably solicit more help from CCs
Awais will put a how-to on the wiki
good-first-issue ? Not yet, but once the how-to is more fleshed out, that could be good
Fea
Django 5.1?
aximprovements is currently turning the warnings into tickets
which will let us get more good-first-issues for fixing those