# \[Invitation\] Frontend-base Release Strategy Summit: August 27, 2025
**URL:** https://discuss.openedx.org/t/invitation-frontend-base-release-strategy-summit-august-27-2025/16876
**Category:** Frontend
**Created:** [August 21, 2025, 1:29pm UTC](https://discuss.openedx.org/t/invitation-frontend-base-release-strategy-summit-august-27-2025/16876 "2025-08-21T13:29:48Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@arbrandes](https://discuss.openedx.org/u/arbrandes)
#### Post date: [August 21, 2025, 1:29pm UTC](https://discuss.openedx.org/t/invitation-frontend-base-release-strategy-summit-august-27-2025/16876/1 "2025-08-21T13:29:48Z")
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](https://openedx.atlassian.net/wiki/spaces/COMM/pages/5178359809/2025-08-27+Frontend-base+Release+Strategy+Summit), 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](https://meet.google.com/wxe-myxy-uei)
Cheers!
---
### Author:  [@braden](https://discuss.openedx.org/u/braden)
#### Post date: [August 21, 2025, 8:16pm UTC](https://discuss.openedx.org/t/invitation-frontend-base-release-strategy-summit-august-27-2025/16876/2 "2025-08-21T20:16:33Z")
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/](http://apps.example.com/authn/) (isolated MFE) or at [learn.example.com/authn/](http://learn.example.com/authn/) (frontend-base) and either one would work?
---
### Author:  [@nsprenkle](https://discuss.openedx.org/u/nsprenkle)
#### Post date: [August 21, 2025, 8:48pm UTC](https://discuss.openedx.org/t/invitation-frontend-base-release-strategy-summit-august-27-2025/16876/3 "2025-08-21T20:48:16Z")
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.