How would you design API versioning for an ASP.NET Core service used by external clients?

In production a version has an owner, introduction date, supported-client evidence, deprecation date, and measurable removal criteria. Telemetry records requested versions and known client identity without collecting unnecessary personal data, so the team can distinguish dormant traffic from active partners. I test default-version behavior explicitly rather than letting a library upgrade change it. Version selection at gateways, caches, SDK generation, authorization policies, and observability remains consistent. Breaking changes to database schemas, events, and shared libraries may outlive the HTTP migration, so expand-and-contract deployment keeps both API versions functional during rolling releases and rollback. Security fixes are backported according to the support policy instead of leaving an old version indefinitely exposed. Before removal I verify usage, communicate directly with affected consumers, return clear deprecation signals during the window, and keep a bounded recovery plan. The best strategy still minimizes versions by evolving contracts additively whenever that remains honest.