[Anderkent]

>That deprecated usage should be replaced before it is removed; and if we're talking about skipping multiple major versions over a long period, the replacement likely didn't exist in the older version, so this method still wouldn't work.

the answer to that problem in this approach is to do multiple step upgrades, rather than skipping

serious frameworks/languages do not remove methods in the same version that introduces a replacement, that's the point of having a deprecation mechanism in the first place

[alias_neo]

> the answer to that problem in this approach is to do multiple step upgrades, rather than skipping

That's what I said

> That deprecated usage (of the thing being deprecated) should be replaced (in your code, with the thing that replaced it, in the language/library) before it (the deprecated thing in the language/library) is removed (from the language/library);

The example in OP was that they were upgrading major versions after-the-fact, so they've missed the transition period (say, 2 major versions, after which deprecations are removed).

In my experience it has often not been beneficial to try and upgrade through multiple versions after the fact, when instead a big-bang update provides opportunities to improve the overall structure and quality of the code, because those things that were deprecated were done for a reason, and the thing being upgraded may have improved significantly in structure, usage, performance, etc in that time.