One way I'd approach this: Instead of adding a deprecation warning in the new release, go ahead and throw the full-blown exception and log it as such. The exce

One way I'd approach this: Instead of adding a deprecation warning in the new release, go ahead and throw the full-blown exception and log it as such. The exception message can contain instructions for resolving the concern, links to documentation, et. al. I know the way we specialize and divide labor makes this kind of thing suck in many shops, but the counterpoint is that by "just fixing it now", you don't really have to worry about all of this weird cruft accumulating over time. eventually you will get rug-pulled one way or the other, so why not incrementally shore up your usage as the API changes over time? From a legal & B2B perspective, this might also be considered desirable. If your customers have to stay closely-aligned to your happy path, you won't have to send in seal team 6 to rescue some deprecated pile of shit or otherwise worry about weird, unsupported combinations of state & configuration building up over time.