Hacker News Reader

Comment by adewinter | Hacker News Reader

If you do the above, your prod servers will always run in "deprecated allow" mode because developers continue to use (and add new) deprecated functionality. That's what the article is attempting to tackle.

Why not use profanity in code? We're all adults.

View on HN

Prod should always be running in allow mode anyway for the same reason that prod builds compile out debug asserts and static type checks. Once the code passes review and makes it into prod you've already lost and spitting out warnings on every function invocation will just piss off your ops team.

Right. So what's the point of having @deprecated tags and a deprecated fail mode if you can't ever use it?

Tests.

Okay, so first you have to have a whitelist of "allowed" usages of depreciated functionality for this to actually work. Anything that makes it into prod goes on the whitelist. All dev environments, QA, and your automated testing run with fail mode on and trying to push code that adds to the whitelist should set off alarm bells. From there it's up to the team / business if it's worth doing it anyway.

You use it when testing and you can turn deprecation flags on and off. Even on a single production machine/vm.

You can run tests in deprecation not-allow mode. You can run a single VM in deprecation not allow mode.

I understand that naming features as not supported also makes sense. But to me that is what feature toggles are for.

> Why not use profanity in code? We're all adults.

You just answered your own question there.

I think you're saying adults do not use profanity, but that doesn't really make sense.

Adults use words appropriately, not spamming profanity to the point that it's meaningless.

If it's “meaningless”, its not profanity. I don't see your point.

Reply on news.ycombinator.com