[Invitation] Frontend-base Release Strategy Summit: August 27, 2025

Working Groups Frontend
1

We’re coming up on the Ulmo cut from master (which should happen some time in October) and need to decide if and how to offer frontend-base-converted MFEs for use by operators during this release cycle. Do we merge to master before the cut - trying to minimize breaking changes, which may not be possible for Ulmo (or at all) - or do we treat the converted MFEs as a new, independent Open edX client, thus giving us a greener but less familiar (read: more breaking changes) field to work on?

You’ll find a more comprehensive write-up of the context at the summit page in the wiki, but feel free to discuss the matter here. The meeting will happen on Wednesday, August 27, 2025 from 15:00 to 17:00 UTC. If you want an calendar invite, let me know! Link to the meeting itself below:

Frontend-base Release Strategy Summit Meeting

Cheers!

2

Could we do something like the following?

  • Just before each individual MFE is converted to frontend-base, create an ulmo-legacy branch of that MFE.
  • Merge the frontend-base version to master, creating a new major version of that MFE with all the breaking changes you’ve outlined. Support all developers and operators who work off master in upgrading and using the new versions ASAP.
  • Feature freeze on ulmo-legacy branch - all development should only happen on master, with bugfixes being welcome to be backported to ulmo-legacy
  • Operators deploying Ulmo release can choose to either use ulmo-legacy (more compatible) or the new frontend-base versions, or any combination they want (mix and match?). But the frontend-base versions likely have more features, and ideally would have other selling points (faster loading? faster builds? nicer URLs?)

Question: Is it possible to deploy both the frontend-base versions and the legacy versions at the same time? so e.g. I could access authn at apps.example.com/authn/ (isolated MFE) or at learn.example.com/authn/ (frontend-base) and either one would work?

1 Like
3

Echoing @braden’s proposal, I like the following:

  1. Creating 2 separate branches, one pre-frontend-base and post-frontend-base (could use main).
  2. Having a short period (perhaps one named release cycle) of back-porting changes from frontend-base version to the legacy-frontend versions, with the explicit intent of stopping back-porting after that time. This would promote cutover to new frontend tech while giving time for operators to upgrade or plan for divergence.
1 Like