[APIView] WI-12: PR Promotion-on-Merge
- Dominant language
- C#
- Stars
- 135
- Forks
- 260
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 130
Description
## Goal
When a PR is merged and the post-merge API surface matches the PR's latest revision, promote the PR version to `Stable`/`Preview` in-place, preserving comments and avoiding blob duplication.
**Area:** PR Lifecycle · **Depends on:** WI-8, WI-11 · **Stable alone:** ✅ Yes — adds new code path; non-promotion fallback still works
## Deliverables
### Implement `PromotePRVersionAsync`
Add to `APIVersionsManager`:
1. **Trigger:** When `AutoReviewService.CreateAutomaticRevisionAsync` processes a post-merge CI build, check for recently merged PR version whose latest revision `ContentHash` matches incoming hash.
2. **Match found (API unchanged):** Promote in-place:
- Set `Kind` → target kind (`Stable`/`Preview` per `NormalizeVersion`)
- Update `VersionIdentifier` from `"PR#1234"` → normalized version string
- Set `PRStatus = Merged`, retain `PullRequestNumber`/`SourceBranch` for provenance
- **Do not change `Id`** — all PR review comments survive into release version
- **Do not upload new blobs** — reuse PR's existing artifacts
- Record `Promoted` in `ChangeHistory`
- Skip normal `CreateAutomaticRevisionAsync` flow
3. **No match (API changed post-merge):** Create new version through normal flow. Set `PRStatus = Merged` on PR version (follows merged-PR retention).
### Tests
- `APIVersionsManagerTests.cs` — Promotion preserves Id/comments/blobs, updates Kind/VersionIdentifier; non-matching creates new version
- `AutoReviewServiceTests.cs` — Post-merge triggers promotion check; promotion skips revision creation; hash mismatch falls through
### Documentation
Update `docs/overview.md` §4c (PullRequestManager) and `docs/release_approval.md` §7 for promotion-on-merge flow.
Contributor guide
Research direction
Start with APIVersionsManager and AutoReviewService.CreateAutomaticRevisionAsync, then read APIVersionsManagerTests.cs and AutoReviewServiceTests.cs for the promotion and hash-mismatch cases. Update docs/overview.md §4c and docs/release_approval.md §7. Done means matching post-merge PR versions are promoted in place with identity, comments, and blobs preserved, while mismatches use the normal flow and the tests pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- api
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100