Welcome to the Dreevpeeve of the day. I’ve actually seen “deprecate” misused so often that I was worried that, as usual, the prescriptivists would soon have to concede defeat. But so far all the dictionaries are holding firm. This is merely in the category of Common Misconception and so I’m doing my part with this blog post to hold the line. We don’t want another “literally” on our hands here.
First, what it actually means to deprecate something:
- To express disapproval of it
- To play it down or belittle or disparage it
- To withdraw official support for it or discourage the use of it in favor of a newer or better alternative (chiefly of software)
- To seek to avert it, or (archaic) to pray against it
Definition 3 is the one people are confused about. But as you can see, they’re all variations on the same theme. Google’s dictionary (which I hate, but that’s a story for another blog) groups the software definition of “deprecated” with their main “disapproved of” definition:
(Chiefly of a software feature) [to] be usable but regarded as obsolete and best avoided, typically due to having been superseded. “This feature is deprecated and will be removed in later versions.”
“Deprecated” just means “disapproved of”
The Common Misconception is betrayed, for example, in this request (edited to protect the innocent) from one of our integration partners:
We’d appreciate it if you can update Beeminder to not use [thingamabob] so that we can hopefully deprecate it.
You’re not hopefully deprecating it, you’ve deprecated it, right there in the first half of the sentence. What you hope is to actually remove the old thingamabob! [1]
Here’s another example I found — someone talking about a thing from OpenAI called the Assistants API:
They promise more to come, and that chat completions will be supported going forward but they plan to deprecate the Assistants API mid-2026.
What OpenAI actually says:
[After the Responses API subsumes the Assistants API] we plan to formally announce the deprecation of the Assistants API with a target sunset date in the first half of 2026.
It’s admittedly confusing, talking about a plan to formally deprecate something. I even found an example of us falling for this ourselves, culled from Twitter back in 2013:
@fitbit you deprecated activeScore a month early! The api is returning -1 as of Sept 28th, not Oct 29 per [rotted link to Fitbit support forum]
I’m almost surely the one who wrote that, and am duly embarrassed. [2] Presumably I was following Fitbit’s misuse of the term.
I polled beemail subscribers on this a few months back. They’re super savvy and mostly didn’t actually recall hearing this kind of misuse. [3] But I predict that now that I’ve pointed it out you’re going to hear it all the time. Please glare disapprovingly when you do.
Footnotes
[1] In the case of deprecating old URLs, we recommend just adding them to an eternal list of legacy redirects and not worrying about how big that list gets. Even over decades it’ll stay perfectly wieldy. We’re old enough to know! The failure to create permanent legacy redirects for old URLs is definitely another Dreevpeeve.
[2] Conceivably it was Bee. She’s the one who was (still is) dealing with Fitbit’s API. But I’ve almost always manned the Twitters and whatnot.
[3] One of those savvy beemail subscribers came up with a steelmanning of at least one of these supposed misuses. You could read “we’ll hopefully deprecate it” as shorthand for going through a formal deprecation process, with the usual warnings in the documentation, culminating in eventual removal of support for the thing. Perhaps this conflation of “deprecation with scheduled removal” and mere deprecation is the source of the Common Misconception.