/
2027-07-31 Frontend Working Group Meeting Notes: frontend-base branching and release strategy

2027-07-31 Frontend Working Group Meeting Notes: frontend-base branching and release strategy

 Date, time, location

 Discussion topic(s)

  • State of the frontend-base work (@Adolfo Brandes)

  • Proposal for new branching/publication strategy (@Adolfo Brandes)

🎥Recording

 Participants

The list of participants, tagged if they’re registered in Confluence.

🤖 Summary

1. Frontend Base Overview

  • Conference Workshop Reference: Adolfo and Brian presented at a conference; a recording will be published soon as a reference for how frontend-base works.

  • Current Status:

    • frontend-base is published as v1.0-alpha.5.

    • Usable for specific repos and avoids Mac/Linux inotify watch limits.

    • frontend-base acts as a library; frontend apps (e.g., frontend-app-authn, frontend-app-learner-dashboard) are now dependencies.

    • Sites can be created from a frontend template repo—fully customizable without upstream merges.

    • Apps can be bundled together in a single SPA for better code reuse and faster navigation, instead of separate deployments per MF.

  • Backward Compatibility:

    • Possible to still deploy apps separately to different domains if desired (e.g., edx.org or 2U deployments).

    • Some apps (e.g., profile, account) are not yet frontend-base-converted but can still integrate with converted apps.

2. Proposed Branching & Release Strategy (ADR)

  • New “next” Branch:

    • All new features land in next first.

    • Not production-supported—can contain breaking changes.

    • Linear history, never rebased.

  • Master Branch:

    • Remains initially but in maintenance mode.

    • May be deprecated after full migration.

  • Release Branches:

    • Stable releases cut from next into branches like 1.x, 2.x, etc.

    • Alpha/next tags published from next for testing.

    • Breaking changes only allowed at the initial release of a major version branch.

  • Cadence & Alignment:

    • Targeting 6-month cycles, aligning with Open edX releases.

    • Non-breaking fixes may be backported to current stable branches.

  • Versioning Debate:

    • Decided to keep semantic meaning (major = breaking changes) for clarity with forks.

    • Avoids always bumping major versions unnecessarily.

3. Deprecation Plans

  • Master Deprecation:

    • Once all MFEs are frontend-base-converted and stable releases exist, master may be renamed (e.g., old-master) and next renamed to main.

    • Post-deprecation, no merging from next to master.

  • Legacy Feature Support:

    • Certain features in master may be removed or unsupported in frontend-base versions.

4. DEPR Proposals (Deprecations)

  • Third-Party Service Integrations:

    • Plan to remove built-in support for analytics/tracking services (e.g., Algolia, Google Analytics, Hotjar, Optimizely, Segment, Zendesk, robots.txt).

    • Users can re-implement via plugins/slots.

    • Segment: Complex due to deep integration across MFEs; minimal support planned in frontend-base.

  • frontend Experiments:

    • Removal of short-lived experimental code (already mostly removed from learner-dashboard).

  • Configurable edX Fields Shortcut:

    • Deprecated; replaced by existing configuration methods.

5. Key Decisions & Next Steps

  • Gather feedback on ADR by August 14, 2025.

  • Begin creating next branches soon after agreement.

  • Coordinate with stakeholders (e.g., Paragon team, 2U, http://edx.org ) on tracking hooks and plugin strategies.

  • Keep communication via Slack (wg-frontend).

Main Takeaways

  • frontend-base represents a major architectural shift: moving to library-based modular apps, easier customization, and consolidated SPAs.

  • Branching strategy aims to separate experimental/breaking work (next) from stable releases while allowing predictable upgrade paths.

  • Deprecations will simplify core code by offloading specific integrations to plugins/extensions.

 Action items

 Decisions