<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=587138) </details> <!--IssueSummary end--> Add migration-safe mechanism for supporting both v1 and v2 approval rules simultaneously during transition. ## What 1. Database migration: Add approval_rules_version column to merge_requests table (enum: v1, v2; default: v1) 2. Create service: When FF is enabled, set new MRs to approval_rules_version = 'v2' 3. Update service: Check MR's approval_rules_version flag instead of FF - v1 MRs → use v1 approval rules logic - v2 MRs → use v2 approval rules logic 4. Individual rule services (Create, Update, Destroy): Check MR's version flag to determine which rules table to operate on 5. Tests: Verify both v1 and v2 MRs work correctly ## Why Enables safe rollout where: - Existing v1 MRs continue to work unchanged - New v2 MRs use the new system - Both versions coexist during migration period ## Migration Strategy - Phase 1: Add flag, update services to use it (this issue) - Phase 2: Enable FF in production (new MRs use v2) - Phase 3: Backfill existing MRs to v2 (separate issue) - Phase 4: Remove v1 code (after backfill complete)