Most API versioning discussions are about where the version goes - the URL, a header, a media type - which is the least consequential decision in the whole area. The consequential one is what you commit to when you publish version one, because every version you have ever released is a version you are maintaining until you can prove nobody uses it.
The first thing worth being precise about is what constitutes a breaking change, because teams routinely ship breaking changes believing they have not. Removing a field is breaking. Renaming one is breaking. Making an optional request field required is breaking. Narrowing what a field accepts is breaking. Adding a new value to an enumeration is breaking for any client that switches exhaustively on it - which is most typed clients. Adding an optional field, or a new endpoint, is safe.
Given that, the cheapest strategy is to avoid needing a new version at all. Additive change, tolerant readers - clients that ignore fields they do not recognise - and defaults for anything new will carry an API a long way. A new major version should be reserved for changes to the fundamental model, not for tidying up naming. Every version you avoid creating is a version you never have to retire.
When you do version, publish the deprecation policy at the same time as the version, not later. How long a version is supported after its successor ships, how much notice of retirement clients receive, and where that notice appears. Twelve months of support and six months of notice is a defensible default for a business API. Announcing a policy retrospectively, when you already want something gone, is how you end up unable to remove it.
Deprecation only works if you can see who is affected, so instrument by version and by client from the beginning. When retirement approaches you want to name the four accounts still calling version one and contact them, rather than sending a broadcast email and hoping. Serve the Deprecation and Sunset headers on responses from the old version too - some client libraries surface them, and it costs nothing.
The endgame that works is a scheduled brownout: take the old version offline for an hour, announced in advance, then a day, then permanently. Clients that missed every email discover the problem at a moment you have chosen and can reverse, rather than at a moment you have not. Teams that skip brownouts either never retire anything, or retire it and spend the following week on emergency support calls.
