Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
We should document every fix/improvement that lands on frontend-base that would make sense to backport to master, and open backport PRs only once they land
“BOTH”: tutor-mfe should support both a built-in frontend-site, and the ability to specify custom, externally managed frontend-site repositories (or, separate SPAs)
The group decided to prioritize merging the full React Query migration PR for Learner Dashboard master (led by Jacobo Dominguez) before landing the Programs Dashboard conversion PR (led by Max/Jason Wesson).
Operators can deploy converted MFEs optionally, on a per MFE basis, for at least one release, and at most two releases
For a period of time there will be two branches, and at some point there will be only one: the choice should be up to the maintainer of the repo
Development should default to frontend-base ASAP
Support operators who use master to be able to choose and test frontend-base
Coordinate with individual maintainers on how the frontend-base branch evolves
Communicate to current maintainers things they should/shoudn’t do that will make porting to frontend-base easier
Library upgrades such as react-router from v5 to v6, or react-query from v4 to v5, should happen in master before the frontend-base branch
Do not start converting any new MFEs until the missing features have been tackled, and based on that, a new decision is arrived at on whether any new MFEs will be converted at all for the following release
Any newly developed MFEs that are targetting Verawood or beyond should be developed on frontend-base only