Publish frontend-app-notifications 3.0.0

[arbrandes]

Description

Publish @openedx/frontend-app-notifications 3.0.0 (the frontend-base rewrite) as the new stable, by adopting the release-branch model from ADR 0012 (amended in openedx/frontend-base#274). Part of openedx/frontend-base#244.

This repo is the odd one out. Today main carries the old architecture (last stable v2.0.11, published as @edx/frontend-plugin-notifications) and frontend-base carries the rewrite (3.0.0-alpha.3, published as @openedx/frontend-app-notifications to @latest). The two branches have diverged (shared base, then main +11 / frontend-base +23, entirely different trees), and the old and new code are different npm packages.

End state: main becomes the unstable dev branch by adopting the rewrite (retiring frontend-base), and release publishes 3.0.0 to @latest. The old architecture is preserved on a frozen 2.x branch that is deliberately left out of the release automation (see Notes). This differs from the other apps: notifications reclaims main as its dev branch, because main is a live branch rather than dead legacy.

Separately, this repository is named frontend-plugin-notifications, while its rewrite npm package is @openedx/frontend-app-notifications. As part of this work the repository should be renamed to frontend-app-notifications, to match the package name and the sibling MFEs.

"branches": [
  { "name": "release", "channel": "latest" },
  { "name": "main", "prerelease": "alpha", "channel": "alpha" }
]

Plan

• Rename the repository frontend-plugin-notifications -> frontend-app-notifications, to match the npm package name and the sibling MFEs.

• Bump the @openedx/frontend-base dependency to ^1.0.0 (the released stable) on frontend-base.

• Cut 2.x from current main to preserve the old architecture as a frozen branch.

• Land the rewrite onto main using the technique from Land frontend-base frontend-base#243 (see Notes), then retire the frontend-base branch.

• Set .releaserc on main to the target config (release + main only) and point release.yml at [main, release].

• Cut release from main (no-op), then dry-run semantic-release to confirm it computes 3.0.0.

• Configure the 2.x branch to auto-publish to @edx/frontend-plugin-notifications.

• Fast-forward release up to main to publish 3.0.0 to @latest.

• Create the v3.0.0 GitHub Release by hand, with curated notes (see Notes).

• Add branch protection to release; deletion-protect 2.x so the frozen history is preserved.

• Verify: @latest = 3.0.0 on @openedx/frontend-app-notifications, and @alpha tracking main.

Notes

Use a release branch, not an n.x branch, for the current stable. semantic-release classifies n.x names as maintenance branches, which can only patch a major that already shipped, never originate one.

The old and new code are different npm packages: the 2.x line is @edx/frontend-plugin-notifications (legacy @edx scope), while the rewrite is @openedx/frontend-app-notifications. 2.x is therefore kept as a frozen preservation branch.

Set channel: alpha explicitly, or prereleases land on a dist-tag named after the branch (@main) instead of @alpha.

The first stable release's changelog exceeds GitHub's release-body limit and 422s; the npm publish still succeeds, so create the GitHub Release manually.

Landing the rewrite onto main, following openedx/frontend-base#243. Running -s ours on the frontend-base side keeps the rewrite's tree while recording both histories, then main fast-forwards onto it - no force-push and no tree fixup:

git checkout frontend-base
git merge -s ours main
git checkout main
git merge frontend-base   # fast-forward