servicing-pr

# Servicing PRs PRs targeting `release/*` branches require a specific description format and should include a quirk (AppContext switch) when applicable. When updating progress on a servicing PR, ensure that the description still follows the template. ## Backport Target Branch - If a version is specified, target `release/XX.0` (e.g., `backport to 10` → `release/10.0`) - Otherwise, find the latest `release/XX.0` branch (ignore preview branches like `release/11.0-preview2`) - Verify the branch exists before creating the PR ## PR Title `[release/XX.0] <original PR title>` ## PR Description Template ``` Fixes #{issue_number} Backports #{source_pr_number_if_applicable} **Description** 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. **Customer impact** 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. **How found** 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. **Regression** 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. **Testing** 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. **Risk** 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". ``` ## Quirk (AppContext Switch) A quirk lets users opt out of the fix at runtime, reducing patch risk. Skip when the fix is 100% obvious/risk-free, or when the quirk couldn't be used, like in tools or analyzers. ### Adding a Quirk Add in the class(es) containing code changes: ```csharp private static readonly bool UseOldBehavior37585 = AppContext.TryGetSwitch("Microsoft.EntityFrameworkCore.Issue37585", out var enabled) && enabled; ``` - Change `37585` to the relevant issue number - 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 - If the PR closes multiple issues, pick the most appropriate one for the switch name - Distinguish a recommendation from the staged implementation. Do not say "Quirk added" unless the source change actually includes the switch. ## Validation - PR description follows the template completely (all sections filled) - Quirk added where appropriate with issue number matching the PR description