Land frontend-base

Description

Converting a frontend-app-* repository into an App Repository under OEP-65 changes it too deeply to do the work in place, so each conversion has happened on a long-lived frontend-base branch while the repository's default branch went on building the micro-frontend that operators run and that Open edX releases are cut from. Those branches have been taking ports of the default branch's features and fixes since inception, so when a conversion is done there is nothing left to reconcile: the converted branch simply has to take over.

This epic covers that takeover, for every repository whose conversion branch is live. The mechanism was worked out here and is now settled in OEP-65 ADR 0004, with the branch and release consequences settled in OEP-10 ADR 0002 and ADR 0003.

The merge

Do not attempt a regular merge. The two branches have diverged across nearly every file, and a conflict resolution that large is both enormous and pointless, since the result wanted is simply the conversion branch's tree. Merge with the ours strategy instead, which keeps that tree wholesale while still joining the two histories. Immediately before it, cut legacy-mfe from the default branch's tip:

git switch master                      # or main
git branch legacy-mfe
git push origin legacy-mfe

git switch frontend-base
git merge -s ours master               # keeps frontend-base's tree, records both parents
git switch master
git merge --ff-only frontend-base      # fast-forward
git push origin master

The first merge produces a commit with frontend-base's tree and both branches as parents. The second is therefore a fast-forward, which is the point: the default branch is never rewritten, so clones, open pull requests, and everything already pointing into its history survive. Once it is pushed, the frontend-base branch has served its purpose and can be deleted.

The end state

After the merge, the repository's branches are governed by OEP-10 ADR 0002. It is no longer branched or tagged for Open edX releases, participating by published version instead, per ADR 0003. The micro-frontend it replaces goes on living on legacy-mfe, which is where any further release/RELEASENAME branches for it are cut, and the repository annotates openedx.org/release: "legacy-mfe" to keep release tooling pointed there for as long as a supported release still ships it.

Per-repository checklist

Each repository below has its own sub-issue. The steps are the same in each:

• Cut and push legacy-mfe from the default branch's tip
• Merge the conversion branch with -s ours and fast-forward the default branch onto it
• Delete the frontend-base branch
• Set openedx.org/release in catalog-info.yaml to "legacy-mfe" if a supported release still ships the micro-frontend, or to null if none does
• Rename the stable line to stable and rewrite .releaserc to the ADR 0002 layout, including the maintenance-branch patterns (part of openedx/public-engineering#563)
• Point branch protection and the publish workflows at the new branch names
• Update the contributing docs and README to describe the new branch layout
• Confirm latest still resolves to the same line and that no already-published version is republished from a different branch
• Repoint string extraction in openedx-translations at the new branch names: in .github/workflows/extract-translation-source-files.yml, the repository's allDualMFEAndBaseJavascriptRepos entry becomes mfe_ref: legacy-mfe / base_ref: master, and a repository not yet listed there moves out of allJavascriptRepos and into that list. Both branches keep shipping strings while a supported release still includes the micro-frontend, and they combine into the single existing resource, so transifex.yml needs no change. openedx/openedx-translations#81673 did this for Catalog.