MCM-33 — Release Catalog and Version Approval

← Back to MCM Nexus overview

As a Nexus Admin,
I want to see every MCM version fetched from the Artifact Registry, explicitly approve which ones customers can install or upgrade to, and deprecate older ones once newer versions are stable,
so that a newly-built version never reaches customers before RevDau has reviewed it, and customers are always offered a safe, current set of versions across whichever release line they're on.

Acceptance Criteria

• Nexus maintains a catalog of MCM releases — version, publish date, and status (PENDING / APPROVED / REJECTED / DEPRECATED) — populated only when the Nexus Admin runs MCM-30's "Fetch Versions" action; there is no automatic background discovery.
• Each version is grouped into a release line by its major.minor (e.g. 1.1.1 belongs to the 1.1 line, 1.2.0 starts the 1.2 line). More than one line can be APPROVED at the same time — e.g. 1.1.1 (the latest patch on the 1.1 line) and 1.2.0 (a newer line) can both be APPROVED simultaneously, so a hotfix to an older line doesn't require adopting the newer line.
• New versions appear in the catalog as PENDING; the Nexus Admin sees them on a dedicated Releases page, grouped by release line, and can Approve or Reject each one.
• MCM-09 — Download MCM Installation Package and MCM-10 — Upgrade an MCM Instance via Nexus only ever offer APPROVED versions — a PENDING, REJECTED, or DEPRECATED version is never installable or offered as an upgrade, even though it already exists in the registry. See MCM-10 for exactly how an instance is offered a same-line patch versus a newer line to jump to.
• Rejecting a version is permanent for that version; a corrected build is published as a new version and goes through approval again — there is no "re-submit the same version."
• Only an already-APPROVED version can be deprecated. Deprecating it removes it from what MCM-09 offers to new installs going forward; instances already running it are not blocked and can keep operating — see MCM-10 for how they're informed and can still upgrade off it.
• Deprecating a version is always an explicit, per-version Nexus Admin action — approving a newer version in the same or a different line never automatically deprecates an older one.
• The Nexus Admin can see the full release history (every version ever published, its release line, its current status, and who changed that status and when), not just the current latest per line.

---

Technical Design

The Release entity in mcm-nexus/backend (version, publishedAt, status PENDING/APPROVED/REJECTED/DEPRECATED, reviewedBy/reviewedAt, deprecatedBy/deprecatedAt) gains a derived majorMinorLine field parsed from version at insert time (semantic major.minor.patch), so multiple lines can independently hold their own APPROVED version. Rows are inserted as PENDING exclusively by MCM-30's POST /api/admin/registry/fetch-versions — this story owns no discovery logic of its own, only the catalog and status transitions. The (admin)/admin/releases page lists releases grouped by majorMinorLine with Approve/Reject actions on PENDING rows and a Deprecate action on APPROVED rows. MCM-09's "version to serve" query now filters to status=APPROVED (excluding DEPRECATED), and MCM-10's upgrade-check resolves two independent queries — latest APPROVED version in the instance's own majorMinorLine, and latest APPROVED version in any newer majorMinorLine — instead of a single global "latest," closing the gap where either story previously implied one global latest version was the only option.

---

UI / Frontend Changes

• New (admin)/admin/releases page: table of every fetched version, grouped by release line, publish date, status, and reviewer/timestamp for each status change, with Approve/Reject actions on PENDING rows and a Deprecate action on APPROVED rows.
• Deprecate action requires a confirmation step, since it changes what new installs are offered going forward.
• Badge/count on the admin nav when releases are pending review, so the Nexus Admin doesn't have to check proactively.
• No customer-facing change here beyond what MCM-09/MCM-10 already show — customers still only ever see version availability and a deprecation notice where relevant, never the underlying approval workflow itself.

---

Out of Scope

• Automated approval rules (e.g. auto-approve after N days) — every version requires an explicit human Approve/Reject for now.
• Per-organization staged rollout (e.g. approving a version for some customers before others) — approval is global, once for all customers.
• Automatically deprecating an older line when a newer one is approved — deprecation is always a separate, explicit Admin action.
• Un-deprecating a version back to APPROVED — once deprecated, a version stays deprecated for this iteration.