Deprecate Like You Mean It

This isn't a good idea regardless of why it's being deprecated.

If it's no longer being maintained then put a depreciation warning and let it break on its own. Changing a deprecated feature just means you could maintain it but don't want to.

Alternatively if you want to aggressively push people to migrate to the new version, have a clear development roadmap and force a hard error at the end of the depreciation window so you know in advance how long you can expect it to work and can document your code accordingly.

This wishy-washy half-broken behaviour doesn't help anyone

Please do the opposite. Let all deprecation warnings last at least a decade, just include in the warning that it is not maintained.

But more to the point, go out of your way to avoid breaking backwards compatibility. If it's possible to achieve the same functionality a different way, just modify the deprecated function to use the new function in the background.

My biggest problem with the whole static typing trend is that it makes developers feel empowered to break backwards compatibility when it would be trivial to keep things working.

No. Breaking other people's code is why we have this broken software world where new bugs (and security holes) are added everywhere all the time since no software is allowed to just exist without monthly rewrites. We need a culture where breaking backwards compatibility in published APIs is almost unthinkable, not something anyone would want to be caught doing.

Don't make it return a different result.

Instead, if you must, add a sleep within the function for 1 ms in the first release, 2 ms in the second release, and so on. But maybe just fix the tooling instead to make deprecations actually visible.

> That would probably not trigger anyone’s midnight pager, but it would make it clear that relying on the deprecated functionality is a bug lurking in the code.

How do you know? This is a wild assertion. This idea is terrible. I thought it was common knowledge that difficult to reproduce, seemingly random bugs are much more difficult to find and fix than compiler errors.

If you're ready to break your api, break your api. Don't play games with me. If more people actually removed deprecated APIs in a timely manner, then people will start taking it more seriously.

Having a deprecated API just randomly return failures is an awful idea!

Better to give an actual timeline (future version & date) for when deprecated functionality / functions will be removed, and in the meantime, if the language supports it, mark those functions as deprecated (e.g. C++ [[deprecated]] attribute) so that developers see compilation warnings if they failed to read the release notes.

I get that it's nice to be able to deprecate/remove things.

But intentionally breaking my users runtime in a way that's really hard and annoying to find? Is the author OK? This reads like a madman to me.

Occasionally returning wrong results is irresponsible, of course, but how about making deprecated APIs grow gradually slower?

Please don’t do this. If you want to remove the function, remove it and insist on its removal when people complain. Don’t gradually break people.

Wow, tell me you've never shipped anything important / heavily used without telling me that.

I expected this to suggest a tick-tock deprecation cycle, where one version deprecated and the next removed, but this is definitely an idea that belongs on the domain "entropicthoughts.com"

sure - because i rewrite all my code every year!

Instead randomly trigger kill self process. That's a safer way than random wrong returns.