|
| 1 | +--- |
| 2 | +name: servicing-pr |
| 3 | +description: 'Create EF Core PRs targeting servicing release branches (release/*). Use when working on a PR that targets a release branch, backporting a fix from main, or when the user mentions servicing, patch, or release branch.' |
| 4 | +--- |
| 5 | + |
| 6 | +# Servicing PRs |
| 7 | + |
| 8 | +PRs targeting `release/*` branches require a specific description format and should include a quirk (AppContext switch) when applicable. |
| 9 | + |
| 10 | +## Backport Target Branch |
| 11 | + |
| 12 | +- If a version is specified, target `release/XX.0` (e.g., `backport to 10` → `release/10.0`) |
| 13 | +- Otherwise, find the latest `release/XX.0` branch (ignore preview branches like `release/11.0-preview2`) |
| 14 | +- Verify the branch exists before creating the PR |
| 15 | + |
| 16 | +## PR Title |
| 17 | + |
| 18 | +`[release/XX.0] <original PR title>` |
| 19 | + |
| 20 | +## PR Description Template |
| 21 | + |
| 22 | +``` |
| 23 | +Fixes #{issue_number} |
| 24 | +Backports #{source_pr_number_if_applicable} |
| 25 | +
|
| 26 | +**Description** |
| 27 | +Provide information on the bug, why it occurs and how it was introduced. Put it in terms that developers can understand without knowledge of EF Core internals. |
| 28 | +
|
| 29 | +**Customer impact** |
| 30 | +How the bug affects users without internal technical detail. Include a short (3-4 lines) code sample if possible. If data corruption occurs, state that explicitly. If a feasible workaround exists, briefly describe it and how discoverable it is, otherwise mention that there's no workaround. |
| 31 | +
|
| 32 | +**How found** |
| 33 | +How the bug was discovered based on the information in the issue description. If user-reported, mention "User reported on <version>". If multiple users are affected, note that. Count the number of upvotes and comment authors to estimate impact. |
| 34 | +
|
| 35 | +**Regression** |
| 36 | +Whether this is a regression from an earlier EF version. Add a link to the PR that introduced the regression if known. If it only affects a feature introduced in the same major version, it is not a regression. |
| 37 | +
|
| 38 | +**Testing** |
| 39 | +State the number of new or modified tests, don't go into details. If test coverage is unfeasible, briefly explain the alternative validation approach that was used. |
| 40 | +
|
| 41 | +**Risk** |
| 42 | +Brief risk assessment ranked from "extremely low" to "high". Note amount of code changed. If the fix is a one-liner, mention that. If a quirk was added, mention "Quirk added". |
| 43 | +``` |
| 44 | + |
| 45 | +## Quirk (AppContext Switch) |
| 46 | + |
| 47 | +A quirk lets users opt out of the fix at runtime, reducing patch risk. Add for all cases where it makes sense. Skip when the fix is 100% obvious/risk-free, or when the quirk couldn't be used, like in tools or analyzers. |
| 48 | + |
| 49 | +### Adding a Quirk |
| 50 | + |
| 51 | +Add in the class(es) containing code changes: |
| 52 | + |
| 53 | +```csharp |
| 54 | +private static readonly bool UseOldBehavior37585 = |
| 55 | + AppContext.TryGetSwitch("Microsoft.EntityFrameworkCore.Issue37585", out var enabled) && enabled; |
| 56 | +``` |
| 57 | + |
| 58 | +- Change `37585` to the relevant issue number |
| 59 | +- Wrap changes with a condition on `!UseOldBehavior37585` so activating the switch bypasses the fix, prefer to minimize the number of times the switch is checked |
| 60 | +- If the PR closes multiple issues, pick the most appropriate one for the switch name |
| 61 | + |
| 62 | +## Validation |
| 63 | + |
| 64 | +- PR description follows the template completely (all sections filled) |
| 65 | +- Quirk added where appropriate with issue number matching the PR description |
0 commit comments