9 ms·

Deprecate like you mean it

70 points by todsacerdoti 11mo ago

WhyOhWhyQ 11mo ago
Another idea is to make the deprecation warning increasingly scary sounding.
- GuinansEyebrows 11mo ago
  "DEPRECATED: i will literally kill you"
  - WhyOhWhyQ 11mo ago
    "Continuing to use this feature is a moral failure on your part and you should be ashamed, your parents should be ashamed, and dishonor will follow you wherever you go."
    - s1mplicissimus 11mo ago
      "If you don't migrate I will tell your mum"
    - GuinansEyebrows 11mo ago
      sorry, i'm not afraid of this. i'll keep using the feature.
xahrepap 11mo ago
> 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.
- pavel_lishin 11mo ago
  Yeah, I agree - this sort of intermittent failure could be incredibly hard to track down, and will absolutely fuck with people's faith in their CI systems as well - a flappy test is the absolute worst kind of test.
- matthewkayin 11mo ago
  I agree, maintainers should just break the API if they're going to do it. At the same time, it's crazy that urllib (the library mentioned in the article), broke their API on a minor version. Python packaging documentation[1] provides the sensible guideline that API breaks should be on major versions. [1] https://packaging.python.org/en/latest/discussions/versioning/ https://packaging.python.org/en/latest/discussions/versionin...
- Certhas 11mo ago
  Last paragraph of the article: > In case the sarcasm isn’t clear, it’s better to leave the warts. But it is also worthwhile to recognise that in terms of effectiveness for driving system change, signage and warnings are on the bottom of the tier list. We should not be surprised when they don’t work.
  - layer8 11mo ago
    Most HN visitors won’t read to the last paragraph, so it’s a good thing to emphasize.
    - xahrepap 11mo ago
      I thought I had read it. :) I thought the three `* * *` at the bottom was indicating I was about to start reading suggestions for the next article. So definitely a "Woosh" moment for me :D
  - xahrepap 11mo ago
    Yeah, totally a woosh moment for me. Read all the way up to the `* * *`. That's on me :)
dec0dedab0de 11mo ago
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. edit: Not that it is always trivial to avoid breaking backwards compatibility, but there are so many times that it would be.
- jkubicek 11mo ago
  > just include in the warning that it is not maintained. I'm convinced this isn't possible in practice. It doesn't matter how often you declare that something isn't maintained, the second it causes an issue with a [bigger|more important|business critical] team it suddenly needs become maintained again.
  - tux3 11mo ago
    And here's where your business can contact me to talk about a support contract. If it's important, they'll pay. Often you find out it wasn't that important, and they're happy to figure it out.
    - nisegami 11mo ago
      It sounds like you're imagining open source whereas the comment you're replying to is imagining more intra-company dependencies.
      - mbreese 11mo ago
        I think deprecation in intra-company code is a completely different beast. You either have a business case for the code or not. And if something is deprecated and a downstream project needs it, it should probably have the budget to support it (or code around the deprecation). In many ways, the decision is easier because it should be based on a business use case or budget reason.
syntheticnature 11mo ago
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"
fwip 11mo ago
Profoundly awful idea.
s1mplicissimus 11mo ago
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.
YetAnotherNick 11mo ago
Instead randomly trigger kill self process. That's a safer way than random wrong returns.
Pingk 11mo ago
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
- pvtmert 11mo ago
  The post is a sarcasm, see the below.
cowsandmilk 11mo ago
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.
HarHarVeryFunny 11mo ago
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.
- psygn89 11mo ago
  Yep. I'll admit I've acted faster to hard set dates than some "in the future" message. I've also seen some tools become really noisy about deprecation spanning many lines AND repeating. Please don't log the same message over and over for each instance. Color or add emoji if you must to grab attention, but once is enough. It's annoying when you can't do anything about it at that time and have to sift through this extra noise when hunting down another issue in the CI log. Add a link that goes over it in more detail and how to migrate for that specific deprecation.
- cortesoft 11mo ago
  I don't think that was a serious suggestion, the article says it is sarcasm near the end. But yes, that would be the worst idea ever.
- coryrc 11mo ago
  Random is bad, but scheduled windows of breakage is good.
pron 11mo ago
Occasionally returning wrong results is irresponsible, of course, but how about making deprecated APIs grow gradually slower?
kibwen 11mo ago
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.
- helle253 11mo ago
  this actually seems like an reasonable technical solution to the non-technical problem that causes deprecations to be ignored in the first place Degrading performance exponentially (1ms, 2ms, 4ms, 8ms...) WILL create a 'business need', without directly breaking critical functions. Without this degradation, there is no reason to remove the deprecated code, from a business perspective.
  - newAccount2025 11mo ago
    It should slow down your compile instead of the runtime. That way the pain is felt by the developer who can fix it.
- shadowgovt 11mo ago
  It is sometimes a tooling issue, but far more often it's a "few teams have a discipline of squashing all toolchain warnings" issue.
- csydas 11mo ago
  I get the intention but it's a bad idea, same with the article if people are meant to depend on your endpoints, they need to be able to depend on all of them you will always have ppl who don't respond to deprecation notices, the best you can do is give them reliable information on what to expect -- if they hide the warnings and forget, that's their business but intentionally making problems without indication that its intentional results in everyone (including your own team) being frustrated and doing more work you cannot force ppl to update their code and trying to agitate them into doing it only serves to erode confidence in the product, it doesn't make the point ppl think it makes, even if the court of public opinion sides with you cover your bases and make a good faith effort to notify and then deal with the inevitable commentary, there will always be some who miss the call to update
mac3n 11mo ago
sure - because i rewrite all my code every year!
1313ed01 11mo ago
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.
froh42 11mo ago
I had the same clever idea once. Deprecation warning, and it would (by the power of a C-Macro) auto-turn off when the relase x was reached, with louder and louder warnings before. One day I came back from holidays. I had just broken a big go-live where the release number passed x. Date missed, next possibility in a few weeks. The team was pissed. Yes they COULD have fixed the warnings. But breaking the go live was quite of of proportion for not doing so.
- zahlman 11mo ago
  Could the clients have reasonably foreseen when the release x would occur? Could they not have rolled back?
xd1936 11mo ago
Chaotic Evil code.
oivey 11mo ago
It would help a lot if core Python libraries like urllib, NumPy, and others used SemVer. Removing a function is a breaking change. The root of this post is from urllib breaking something in a minor release. Get rid of the pseudo SemVer where you can deprecate functions and then break in minor releases. Maybe after that the rest of the community could hope their code will work long term if they don’t increment major versions.
- graemep 11mo ago
  Python itself is making breaking changes between minor versions, so I think its natural that the ecosystem will follow. I have not had any real problems yet myself, but its worrying.
  - zahlman 11mo ago
    Python has never claimed to use semver, despite everyone associating the 3 in front with the 2->3 migration.
    - graemep 11mo ago
      That just means its always been a problem, instead of being a new problem. It does use major.minor.bugfix versioning, but without clarity about when to expect breaking changes. With the pace of 3.x releases it has become more of a problem.
- kerkeslager 11mo ago
  > Get rid of the pseudo SemVer where you can deprecate functions and then break in minor releases. I agree, but I think there's a bigger, cultural root cause here. This is the result of toxicity in the community. The Python 2 to 3 transition was done properly, with real SemVer, and real tools to aid the transition. For a few years about 25% of my work as a Python dev was transitioning projects from 2 to 3. No project took more than 2 weeks (less than 40 hours of actual work), and most took a day. And unfortunately, the Python team received a ton of hate (including threats) for it. As a natural reaction, it seems that they have a bit of PTSD, and since 3.0 they've been trying to trickle in the breaking changes instead of holding them for a 4.0 release. I don't blame them--it's definitely a worse experience for Python users, but it's probably a better experience for the people working on Python to have the hate and threats trickle in at a manageable rate. I think the solution is for people like us who understand that breaking changes are necessary to pile love on doing it with real SemVer, and try to balance out the hate with support and I had a client who in 2023 still was on 2.7.x, and when I found a few huge security holes in their code and told them I couldn't ethically continue to work on their product if they wouldn't upgrade Python, Django, and a few other packages, and they declined to renew my contract. As far as I know, they're still on 2.7.x. :shrug:
taeric 11mo ago
This is silly and ignores how things are "deprecated" in every other practice on earth. Do we still install knob and tube electricity? Absolutely not. Is there still some out there that somebody is supporting some? Of course. Does this mean that people and places shouldn't migrate out of older practices? No. But people have different priorities. And sure, we may treat "squeaky wheel policies" as a bad idea, but quite frankly that is far and away the most common policy out there. To that end, please don't go out of your way to insist that your priority is everyone else's priority.
wombatpm 11mo ago
How are you supposed to deal with recalcitrant users? I work for an organization that is ending support for several long running APIs. And by support I mean turn off the servers, you must move to an entirely new platform. We’ve sent out industry alerts, updated documentation and emailed all user. The problem is the contact information goes stale. The developer who initially registered and set up the keys, has moved on. The service has been running in production for years without problems and we’ve maintained backwards compatibility. So do we just turn it off? We’ve put messages in the responses. But if it’s got 200ok we know no one is looking at those. We’ve discussed doing brownouts where we fail everything for an hour with clear error messages as to what is happening. Is there a better approach? I can’t imagine returning wrong data on purpose randomly. That seems insane.
- ryandrake 11mo ago
  Step 1: Stop thinking of them as "recalcitrant". They're not recalcitrant. They bought (presumably for money) a product, and expect that product to keep working as long as they need it to! They don't expect the vendor to pull the rug out from under them and break it just because the API is old and icky and their software engineers are sad to keep it around. Instead of "deprecate like you mean it" the article should be: "Release software like you mean it" and by that, I mean: Be serious. Be really, really sure that you are good with your API because users are going to want to use it for a lot longer than you might think.
  - tormeh 11mo ago
    Software evolves over time, along with business needs. What seemed like (or even was!) a good idea at some point will almost surely cease to be a good idea at some point in the future. Breaking the API is totally fine if there's a good reason and it's carefully managed.
  - kerkeslager 11mo ago
    I agree, get the API right as much as possible so it doesn't need to be deprecated. But, perfection isn't realistic. If you don't have a plan for when you get things wrong, you're failing to plan for the inevitable.
kerkeslager 11mo ago
Jesus, what a terrible idea. This is such a terrible idea that I would not hire this guy based on this post alone. What I want from code is for it to a) work, and b) if that's not possible, to fail predictably and loudly. Returning the wrong result is neither of the above. It doesn't draw attention to the deprecation warnings as OP intended--instead, it causes a mysterious and non-deterministic error, literally the worst kind of thing to debug. The idea that this is going to work out in any way calls into question the writer's judgment in general. Why on earth would you intentionally introduce the hardest kind of bug to debug into your codebase?
neilv 11mo ago
> What if we intentionally made deprecated functions return the wrong result … sometimes? Every time it intentionally returns the wrong result, it logs the deprecation warning.1 What if we found that a highway overpass construction material was suboptimal, and we want people to use superior materials, so, every now and then, we send a chunk of concrete plummeting down to the ground, to kill a motorist? Thanks to deprecating like we mean it, they're going to replace that overpass sooner than they would otherwise. You'll thank me later. From the https://sethmlarson.dev/deprecations-via-warnings-dont-work-for-python-libraries https://sethmlarson.dev/deprecations-via-warnings-dont-work-... that the post opens with: > This API was emitting warnings for over 3 years in a top-3 Python package by downloads urging libraries and users to stop using the API and that was not enough. We still received feedback from users that this removal was unexpected and was breaking dependent libraries. Entirely predictable. Even many of those who saw the deprecation logging, and bothered to make a conscious decision, didn't think you'd actually break the API. > We ended up adding the APIs back and creating a hurried release to fix the issue. Entirely predictable. Save yourself some anguish, and don't break API unnecessarily. Treat it like a guarantee, as much as possible. If it's a real problem for ongoing development, consider using SemVer and multiple versions, like the linked article suggests. (With the deprecated branch getting minimal maintenance: maybe only select bug fixes, or only critical security fixes, maybe with a sunset on even those, and a deprecation warning for the entire library when it's no longer supported.)
dragonwriter 11mo ago
I don't think deprecation should come with hostile signalling like this, but if it did, it should be consistent, and escalating with subsequent releases, performance regressions on the deprecated path, starting at least one release after the deprecation warning, not wrong results. And it should be explicitly mentioned in the deprecation warnings. (You don't want to break systems, but you want something people who care about the system will investigate, and will quickly find and understand the source of and understand what to do.)
mxey 11mo ago
It is wild to realize that this is the same author as https://entropicthoughts.com/you-want-technology-with-warts https://entropicthoughts.com/you-want-technology-with-warts
- baobun 11mo ago
  There is a new last line of TFA: > In case the sarcasm isn’t clear, it’s better to leave the warts. But it is also worthwhile to recognise that in terms of effectiveness for driving system change, signage and warnings are on the bottom of the tier list. We should not be surprised when they don’t work. Looking at comments I guess everyone whooshed.
ryandrake 11mo ago
Ugh, I am finding it hard to express how much I hate this. Software developers have enough treadmills they need to stay on. Deliberately breaking backward compatibility in the name of "deprecating something old" doesn't have to be one of them. Please don't be that platform or library that deprecates and removes things and makes me have to dust off that old software I wrote in 2005 to move over to a different set of APIs just to keep it working.
schnable 11mo ago
This is a bad idea. But in the same spirit, a bad but less bad idea: require the user to actively enable the deprecated feature via config or something, but have a known schedule to eventually expire it (with a hard error, not randomly incorrect data) and force the user to re-enable it. Causes some pain but not random, hard to track down bug. More like dealing with expiring certs - eventually, the user will want a permanent fix.
SuperNinKenDo 11mo ago
What about a sleep? Each release that the feature gets more deprecated, the program adds a couple milliseconds of just blocking. Less destructive, and gives a nice slow ramp up with real but non-destructive consequences.
mxey 11mo ago
The article has a new note at the bottom: > In case the sarcasm isn’t clear, it’s better to leave the warts.
- phyzome 11mo ago
  Wow, that wasn't there from the start? That explains a lot of the comments here.
deleted 11mo ago
[deleted]
dspillett 11mo ago
> The response.getheader method in urllib has been deprecated since 2023 … When the method was eventually removed, lots of code broke. Two years doesn't seem long to me for a widely used project, unless you have an LTS version that people needing more stability can use, or you are upfront that your API support is two years or less. Of course API support of less than two years is fine, especially for a project that people aren't paying for, but personally I would be quite explicit from the outset (in fact I am with some bits I have out there: “this is a personal project and may change or vanish on a whim, use it in any workflow you depend on being stable at your own risk”). Or am I expecting a bit much there? If using semver or similar you are fine to break the API at a major release point, that is what a major release means, though it would be preferable for you to not immediately stop all support for the previous major version. > What if we intentionally made deprecated functions return the wrong result … sometimes? Hell no. A complete break is far preferable. Making your entire API essentially a collection of undefined (or vaguely undefined) behaviours is basically evil. You effectively render all other projects that have yours as a dependency, also just collections of vaguely defined behaviours. If your API isn't set in stone, say so then people have nothing to complain about unless they specifically ask you to keep something stable (and by “ask you to keep something stable” I mean “offer to pay for your support in that matter”). > Users that are very sensitive to the correctness of the results… That is: any user with any sense. > might want to swap the wrong result for an artificial delay instead. That is definitely more palatable. A very short delay to start with, getting longer until final deprecation. How short/long is going to be very dependent on use case and might be very difficult to judge: the shortest needs to be long enough to be noticeable to someone paying attention and testing between updating dependencies and releasing, but short enough that it doesn't completely break anything if someone updates and releases quickly, perhaps to bring in a bugfix that has begun to affect their project. This is still evil, IMO, but a much lesser evil. I'd still prefer the complete break, but then again I'm the sort of person who would pay attention to deprecation notices, so unless you are a hidden nested dependency I'd not be affected.
Lvl999Noob 11mo ago
The various projects that say something is deprecated but then don't give a removal timeline or keep delaying the removal (or even explicitly say it won't be removed, just remain deprecated) are the cause of this problem. IMO, any deprecation should go in the following steps: 1. Decide that you want to deprecate the thing. This also includes steps on how to migrate away from the thing, what to use instead, and how to keep the existing behaviour if needed. This step would also decide on the overall timeline, starting with the decision and ending with the removal. 2. Make the code give out big warnings for the deprecation. If there's a standard build system, it should have support for deprecation warnings. 3. Break the build in an easy to fix way. If there is too much red tape to take one of the recommended steps, the old API is still there, just under a `deprecated` flag or path. Importantly, this means that at this step, 'fixing' the build doesn't require any change in dependencies or (big) change in code. This should be a one line change to make it work. 4. Remove the deprecated thing. This step is NOT optional! Actually remove it. Keep it part of your compiler / library / etc in a way to give an error but still delete it. Fixing the build now requires some custom code or extra dependency. It is no longer a trivial fix (as trivial as the previous step at least). Honestly, the build system should provide the tools for this. Being able to say that some item is deprecated and should warn or it is deprecated and should only be accessible if a flag is set or it is removed and the error message should say "function foo() was removed in v1.4.5. Refer to the following link:..." instead of just "function foo() not found" If the build system has the option to treat warnings as errors, it should also have the option to ignore specific warnings from being treated as such (so that package updates can still happen while CI keeps getting the warning). The warning itself shouldn't be ignored.
shadowgovt 11mo ago
Well written, but author is at the risk of tripping over Poe's Law, especially if readers don't read to the bottom. Author's point is that their modest proposal (and its sibling, introducing intentional delays in resolving the deprecated API pieces) is a bad idea. Instead, author suggests that making the API change at all is begging the question "Who does this API serve?" It is, perhaps, okay actually if the old system never gets deprecated.
- mxey 11mo ago
  > especially if readers don't read to the bottom. That note at the bottom was only added after the article was posted.
kazinator 11mo ago
Deprecation warnings are precisely that --- warnings --- so that people have the option not to act on them. So, it is of little surprise that users exercise one of the two available use case scenarios, which is not acting. There are sophisticated users who care about the quality of their code and care about it breaking as infrequently as possible. Those users follow warnings. Not only warnings that happen by default; they use additional tooling to get extra warnings. The follow up on warnings. Deprecation warnings serve those people. As for the others, who cares. "We generously told you this would be removed, for years". People who ignore warnings related to compatibility and have a workflow whereby your dependencies are not pinned down to specific versions, in some project configuration file, so that they are always getting the latest dependencies, are choosing to inflict breakages on themselves.
burnt-resistor 11mo ago
Code churn is an evil, negative value activity. Design sanely and carefully before settling upon a published, standard contract. Churn of external-facing APIs should be extremely rare to solve essential critical problems, not for pseudo-maintenance bikeshedding. Also, the "it's a hobby" excuse doesn't fly. tl;dr: Stop changing and breaking shit unnecessarily.
nitwit005 11mo ago
I found the referenced article linked at the top interesting: https://sethmlarson.dev/deprecations-via-warnings-dont-work-for-python-libraries https://sethmlarson.dev/deprecations-via-warnings-dont-work-... The underlying complaint seems to be about libraries, rather than user behavior.
eslaught 11mo ago
The solution I've found is to make using the API a hard error with an explicitly temporary and obnoxiously-named workaround variable. WORKAROUND_URLLIB3_HEADER_DEPRECATION_THIS_IS_A_TEMPORARY_FIX_CHANGE_YOUR_CODE=1 python3 ... It's loud, there's an out if you need your code working right now, and when you finally act on the deprecation, if anyone complains, they don't really have legs to stand on. Of course you can layer it with warnings as a first stage, but ultimately it's either this or remove the code outright (or never remove it and put up with whatever burden that imposes).
- tennysont 11mo ago
  I heard a second-hand story about some team at Google who did this, and named the variable something like: I_ACKNOWLEDGE_THAT_THIS_CODE_WILL_PERMANENTLY_BREAK_ON_2022_09_20_WITHOUT_SUPPORT_FROM_TEAM_X=1 a year before the deadline. I would be mildly amused by adding _AND_MY_USER_ID_IS="<user_id>"
- pvtmert 11mo ago
  Love this idea, as it is already implemented in a $FAANG company tool. (used company wide by 80k+ SDEs). I got used to seeing these in the logs and terminal. So much that my brain now automatically ignores it from my view/seeing like it does for my nose.
lisper 11mo ago
> The response.getheader method in urllib has been deprecated since 2023 because the response.headers dictionary is what should be used instead. Then response.getheader should just do that. There is no reason to expose the implementation to the user unless performance is critical.
JaggerJo 11mo ago
Thats madness. Just remove deprecated functions after a reasonable time period.
phyzome 11mo ago
« When the method was eventually removed, lots of code broke. » Well, removing it earlier would just mean that lots of code would break earlier...
deleted 11mo ago
[deleted]
RonanSoleste 11mo ago
Never do this on the job. Its called corporate sabotage and will result in a lot of trouble for you. Its also a generally bad idea. The whole point of deprecation is to let others choose a moment to switch over on their own moment of choosing. If you don't want to maintain it just remove it. It is far nicer behavior. Don't force others in a debugging hell. It makes you a bad person.
npunt 11mo ago
Filed under: trying to solve another domain's problem with only the tools in your domain (this is almost always a bad idea)
mamcx 11mo ago
The sentiment is good but the solution is wrong. The ideal flow, IMHO: 1: Emit warning, and include if possible a deadline ("will be removed in the next major version") 2: After X time, BEFORE the deadline, turn it into a compiler OR linter error, but keep the code 3: Do the appropriated notification in the channels about it of impending doom 4: Doom If this is done correctly, we change the expectations from "warnings LOL!" to "warnings are serious business" that is missing in a lot of contexts
hacker_homie 11mo ago
Make the deprecated method slower with a function from the deprecation release so the longer it goes on until it gets to around a day. then remove the function.
asveikau 11mo ago
> The response.getheader method in urllib has been deprecated since 2023 because the response.headers dictionary is what should be used instead. Who cares? This is such a trivial example, where there is no maintenance cost associated with leaving a dummy method in that does a dictionary lookup. I understand there are times when maintenance costs are substantial, but it's hard to take someone seriously when this is their example. The obsession with newness, and stigmatizing something that doesn't conform to your sense of chasing newness, is really silly.. can you believe it's been deprecated since 2023 and someone still uses it???? 2023 was not some kind of dark ages of distant history.
tennysont 11mo ago
(Notwithstanding that this is a joke) Maybe it's just me, but I read this as a solution that would be implemented internally at a large company to distribute pain/accountability/tech-debt across time to a team which might have high turnover. i.e., a way to align incentives by punishing teams with bombs (via their metrics) in their code, before the bomb actually detonates.
pvtmert 11mo ago
I have 2 better ideas; 1. Start charging money for/of deprecated APIs. Just like Oracle did it with Java 8. - OR - 2. Add a timestamp-based RuntimeException to the very same code-path. If the date is greater than (>) the deprecation date, simply throw RuntimeException. for 100% of the requests, all the time. Yes, it will page someone, and yes, it will get fixed immediately!
sshine 11mo ago
For one customer I do maintenance on a piece of software. Building it produces about two-three dozen deprecation warnings. The whole software stack relies on a cluster of packages that stopped receiving updates 5 years ago. The software is not facing end-users. But it does build using NPM and not via vendored packages. To avoid those warnings, large parts of the code need to be rewritten using a different set of packages. That doesn't get prioritised because it works. The software sucks in many ways, but only from the perspective of an artisan. The customer is happy to ignore warnings as long as the software does its job. There isn't money in fixing things that work because it got old. The incentives for the people putting the deprecation warnings in those packages don't align with the users of those packages. Their timelines and motives are different.
shomp 11mo ago
How about never deprecate
neckardt 11mo ago
I thought the industry solved this by bundling breaking changes in major version updates. V 1.0 - foo introduced V 1.1 - foo deprecated, recommend bar V 2.0 - foo removed, only bar Users can stay on 1.x indefinitely, even if it never receives updates. Development continues on 2.x, eventually 3.x and so on. Users only experience breaking changes when they manually do a major version upgrade.
dJLcnYfsE3 11mo ago
In a bit roundabout way Java 11 added `forRemoval` attribute to `@Deprecated` annotation so developers could indicate they really mean it.

70 points by todsacerdoti 11mo ago

WhyOhWhyQ 11mo ago

Another idea is to make the deprecation warning increasingly scary sounding.

GuinansEyebrows 11mo ago
"DEPRECATED: i will literally kill you"
- WhyOhWhyQ 11mo ago
  "Continuing to use this feature is a moral failure on your part and you should be ashamed, your parents should be ashamed, and dishonor will follow you wherever you go."
  - s1mplicissimus 11mo ago
    "If you don't migrate I will tell your mum"
  - GuinansEyebrows 11mo ago
    sorry, i'm not afraid of this. i'll keep using the feature.

xahrepap 11mo ago

> 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.

pavel_lishin 11mo ago
Yeah, I agree - this sort of intermittent failure could be incredibly hard to track down, and will absolutely fuck with people's faith in their CI systems as well - a flappy test is the absolute worst kind of test.
matthewkayin 11mo ago
I agree, maintainers should just break the API if they're going to do it. At the same time, it's crazy that urllib (the library mentioned in the article), broke their API on a minor version. Python packaging documentation[1] provides the sensible guideline that API breaks should be on major versions. [1] https://packaging.python.org/en/latest/discussions/versioning/ https://packaging.python.org/en/latest/discussions/versionin...
Certhas 11mo ago
Last paragraph of the article: > In case the sarcasm isn’t clear, it’s better to leave the warts. But it is also worthwhile to recognise that in terms of effectiveness for driving system change, signage and warnings are on the bottom of the tier list. We should not be surprised when they don’t work.
- layer8 11mo ago
  Most HN visitors won’t read to the last paragraph, so it’s a good thing to emphasize.
  - xahrepap 11mo ago
    I thought I had read it. :) I thought the three `* * *` at the bottom was indicating I was about to start reading suggestions for the next article. So definitely a "Woosh" moment for me :D
- xahrepap 11mo ago
  Yeah, totally a woosh moment for me. Read all the way up to the `* * *`. That's on me :)

dec0dedab0de 11mo ago

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. edit: Not that it is always trivial to avoid breaking backwards compatibility, but there are so many times that it would be.

jkubicek 11mo ago
> just include in the warning that it is not maintained. I'm convinced this isn't possible in practice. It doesn't matter how often you declare that something isn't maintained, the second it causes an issue with a [bigger|more important|business critical] team it suddenly needs become maintained again.
- tux3 11mo ago
  And here's where your business can contact me to talk about a support contract. If it's important, they'll pay. Often you find out it wasn't that important, and they're happy to figure it out.
  - nisegami 11mo ago
    It sounds like you're imagining open source whereas the comment you're replying to is imagining more intra-company dependencies.
    - mbreese 11mo ago
      I think deprecation in intra-company code is a completely different beast. You either have a business case for the code or not. And if something is deprecated and a downstream project needs it, it should probably have the budget to support it (or code around the deprecation). In many ways, the decision is easier because it should be based on a business use case or budget reason.

syntheticnature 11mo ago

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"

fwip 11mo ago

Profoundly awful idea.

s1mplicissimus 11mo ago

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.

YetAnotherNick 11mo ago

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

Pingk 11mo ago

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

pvtmert 11mo ago
The post is a sarcasm, see the below.

cowsandmilk 11mo ago

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.

HarHarVeryFunny 11mo ago

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.

psygn89 11mo ago
Yep. I'll admit I've acted faster to hard set dates than some "in the future" message. I've also seen some tools become really noisy about deprecation spanning many lines AND repeating. Please don't log the same message over and over for each instance. Color or add emoji if you must to grab attention, but once is enough. It's annoying when you can't do anything about it at that time and have to sift through this extra noise when hunting down another issue in the CI log. Add a link that goes over it in more detail and how to migrate for that specific deprecation.
cortesoft 11mo ago
I don't think that was a serious suggestion, the article says it is sarcasm near the end. But yes, that would be the worst idea ever.
coryrc 11mo ago
Random is bad, but scheduled windows of breakage is good.

pron 11mo ago

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

kibwen 11mo ago

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.

helle253 11mo ago
this actually seems like an reasonable technical solution to the non-technical problem that causes deprecations to be ignored in the first place Degrading performance exponentially (1ms, 2ms, 4ms, 8ms...) WILL create a 'business need', without directly breaking critical functions. Without this degradation, there is no reason to remove the deprecated code, from a business perspective.
- newAccount2025 11mo ago
  It should slow down your compile instead of the runtime. That way the pain is felt by the developer who can fix it.
shadowgovt 11mo ago
It is sometimes a tooling issue, but far more often it's a "few teams have a discipline of squashing all toolchain warnings" issue.
csydas 11mo ago
I get the intention but it's a bad idea, same with the article if people are meant to depend on your endpoints, they need to be able to depend on all of them you will always have ppl who don't respond to deprecation notices, the best you can do is give them reliable information on what to expect -- if they hide the warnings and forget, that's their business but intentionally making problems without indication that its intentional results in everyone (including your own team) being frustrated and doing more work you cannot force ppl to update their code and trying to agitate them into doing it only serves to erode confidence in the product, it doesn't make the point ppl think it makes, even if the court of public opinion sides with you cover your bases and make a good faith effort to notify and then deal with the inevitable commentary, there will always be some who miss the call to update

mac3n 11mo ago

sure - because i rewrite all my code every year!

1313ed01 11mo ago

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.

froh42 11mo ago

I had the same clever idea once. Deprecation warning, and it would (by the power of a C-Macro) auto-turn off when the relase x was reached, with louder and louder warnings before. One day I came back from holidays. I had just broken a big go-live where the release number passed x. Date missed, next possibility in a few weeks. The team was pissed. Yes they COULD have fixed the warnings. But breaking the go live was quite of of proportion for not doing so.

zahlman 11mo ago
Could the clients have reasonably foreseen when the release x would occur? Could they not have rolled back?

xd1936 11mo ago

Chaotic Evil code.

oivey 11mo ago

It would help a lot if core Python libraries like urllib, NumPy, and others used SemVer. Removing a function is a breaking change. The root of this post is from urllib breaking something in a minor release. Get rid of the pseudo SemVer where you can deprecate functions and then break in minor releases. Maybe after that the rest of the community could hope their code will work long term if they don’t increment major versions.

graemep 11mo ago
Python itself is making breaking changes between minor versions, so I think its natural that the ecosystem will follow. I have not had any real problems yet myself, but its worrying.
- zahlman 11mo ago
  Python has never claimed to use semver, despite everyone associating the 3 in front with the 2->3 migration.
  - graemep 11mo ago
    That just means its always been a problem, instead of being a new problem. It does use major.minor.bugfix versioning, but without clarity about when to expect breaking changes. With the pace of 3.x releases it has become more of a problem.
kerkeslager 11mo ago
> Get rid of the pseudo SemVer where you can deprecate functions and then break in minor releases. I agree, but I think there's a bigger, cultural root cause here. This is the result of toxicity in the community. The Python 2 to 3 transition was done properly, with real SemVer, and real tools to aid the transition. For a few years about 25% of my work as a Python dev was transitioning projects from 2 to 3. No project took more than 2 weeks (less than 40 hours of actual work), and most took a day. And unfortunately, the Python team received a ton of hate (including threats) for it. As a natural reaction, it seems that they have a bit of PTSD, and since 3.0 they've been trying to trickle in the breaking changes instead of holding them for a 4.0 release. I don't blame them--it's definitely a worse experience for Python users, but it's probably a better experience for the people working on Python to have the hate and threats trickle in at a manageable rate. I think the solution is for people like us who understand that breaking changes are necessary to pile love on doing it with real SemVer, and try to balance out the hate with support and I had a client who in 2023 still was on 2.7.x, and when I found a few huge security holes in their code and told them I couldn't ethically continue to work on their product if they wouldn't upgrade Python, Django, and a few other packages, and they declined to renew my contract. As far as I know, they're still on 2.7.x. :shrug:

taeric 11mo ago

This is silly and ignores how things are "deprecated" in every other practice on earth. Do we still install knob and tube electricity? Absolutely not. Is there still some out there that somebody is supporting some? Of course. Does this mean that people and places shouldn't migrate out of older practices? No. But people have different priorities. And sure, we may treat "squeaky wheel policies" as a bad idea, but quite frankly that is far and away the most common policy out there. To that end, please don't go out of your way to insist that your priority is everyone else's priority.

wombatpm 11mo ago

How are you supposed to deal with recalcitrant users? I work for an organization that is ending support for several long running APIs. And by support I mean turn off the servers, you must move to an entirely new platform. We’ve sent out industry alerts, updated documentation and emailed all user. The problem is the contact information goes stale. The developer who initially registered and set up the keys, has moved on. The service has been running in production for years without problems and we’ve maintained backwards compatibility. So do we just turn it off? We’ve put messages in the responses. But if it’s got 200ok we know no one is looking at those. We’ve discussed doing brownouts where we fail everything for an hour with clear error messages as to what is happening. Is there a better approach? I can’t imagine returning wrong data on purpose randomly. That seems insane.

ryandrake 11mo ago
Step 1: Stop thinking of them as "recalcitrant". They're not recalcitrant. They bought (presumably for money) a product, and expect that product to keep working as long as they need it to! They don't expect the vendor to pull the rug out from under them and break it just because the API is old and icky and their software engineers are sad to keep it around. Instead of "deprecate like you mean it" the article should be: "Release software like you mean it" and by that, I mean: Be serious. Be really, really sure that you are good with your API because users are going to want to use it for a lot longer than you might think.
- tormeh 11mo ago
  Software evolves over time, along with business needs. What seemed like (or even was!) a good idea at some point will almost surely cease to be a good idea at some point in the future. Breaking the API is totally fine if there's a good reason and it's carefully managed.
- kerkeslager 11mo ago
  I agree, get the API right as much as possible so it doesn't need to be deprecated. But, perfection isn't realistic. If you don't have a plan for when you get things wrong, you're failing to plan for the inevitable.

kerkeslager 11mo ago

Jesus, what a terrible idea. This is such a terrible idea that I would not hire this guy based on this post alone. What I want from code is for it to a) work, and b) if that's not possible, to fail predictably and loudly. Returning the wrong result is neither of the above. It doesn't draw attention to the deprecation warnings as OP intended--instead, it causes a mysterious and non-deterministic error, literally the worst kind of thing to debug. The idea that this is going to work out in any way calls into question the writer's judgment in general. Why on earth would you intentionally introduce the hardest kind of bug to debug into your codebase?

neilv 11mo ago

> What if we intentionally made deprecated functions return the wrong result … sometimes? Every time it intentionally returns the wrong result, it logs the deprecation warning.1 What if we found that a highway overpass construction material was suboptimal, and we want people to use superior materials, so, every now and then, we send a chunk of concrete plummeting down to the ground, to kill a motorist? Thanks to deprecating like we mean it, they're going to replace that overpass sooner than they would otherwise. You'll thank me later. From the https://sethmlarson.dev/deprecations-via-warnings-dont-work-for-python-libraries https://sethmlarson.dev/deprecations-via-warnings-dont-work-... that the post opens with: > This API was emitting warnings for over 3 years in a top-3 Python package by downloads urging libraries and users to stop using the API and that was not enough. We still received feedback from users that this removal was unexpected and was breaking dependent libraries. Entirely predictable. Even many of those who saw the deprecation logging, and bothered to make a conscious decision, didn't think you'd actually break the API. > We ended up adding the APIs back and creating a hurried release to fix the issue. Entirely predictable. Save yourself some anguish, and don't break API unnecessarily. Treat it like a guarantee, as much as possible. If it's a real problem for ongoing development, consider using SemVer and multiple versions, like the linked article suggests. (With the deprecated branch getting minimal maintenance: maybe only select bug fixes, or only critical security fixes, maybe with a sunset on even those, and a deprecation warning for the entire library when it's no longer supported.)

dragonwriter 11mo ago

I don't think deprecation should come with hostile signalling like this, but if it did, it should be consistent, and escalating with subsequent releases, performance regressions on the deprecated path, starting at least one release after the deprecation warning, not wrong results. And it should be explicitly mentioned in the deprecation warnings. (You don't want to break systems, but you want something people who care about the system will investigate, and will quickly find and understand the source of and understand what to do.)

mxey 11mo ago

It is wild to realize that this is the same author as https://entropicthoughts.com/you-want-technology-with-warts https://entropicthoughts.com/you-want-technology-with-warts

baobun 11mo ago
There is a new last line of TFA: > In case the sarcasm isn’t clear, it’s better to leave the warts. But it is also worthwhile to recognise that in terms of effectiveness for driving system change, signage and warnings are on the bottom of the tier list. We should not be surprised when they don’t work. Looking at comments I guess everyone whooshed.

ryandrake 11mo ago

Ugh, I am finding it hard to express how much I hate this. Software developers have enough treadmills they need to stay on. Deliberately breaking backward compatibility in the name of "deprecating something old" doesn't have to be one of them. Please don't be that platform or library that deprecates and removes things and makes me have to dust off that old software I wrote in 2005 to move over to a different set of APIs just to keep it working.

schnable 11mo ago

This is a bad idea. But in the same spirit, a bad but less bad idea: require the user to actively enable the deprecated feature via config or something, but have a known schedule to eventually expire it (with a hard error, not randomly incorrect data) and force the user to re-enable it. Causes some pain but not random, hard to track down bug. More like dealing with expiring certs - eventually, the user will want a permanent fix.

SuperNinKenDo 11mo ago

What about a sleep? Each release that the feature gets more deprecated, the program adds a couple milliseconds of just blocking. Less destructive, and gives a nice slow ramp up with real but non-destructive consequences.

mxey 11mo ago

The article has a new note at the bottom: > In case the sarcasm isn’t clear, it’s better to leave the warts.

phyzome 11mo ago
Wow, that wasn't there from the start? That explains a lot of the comments here.

deleted 11mo ago

[deleted]

dspillett 11mo ago

> The response.getheader method in urllib has been deprecated since 2023 … When the method was eventually removed, lots of code broke. Two years doesn't seem long to me for a widely used project, unless you have an LTS version that people needing more stability can use, or you are upfront that your API support is two years or less. Of course API support of less than two years is fine, especially for a project that people aren't paying for, but personally I would be quite explicit from the outset (in fact I am with some bits I have out there: “this is a personal project and may change or vanish on a whim, use it in any workflow you depend on being stable at your own risk”). Or am I expecting a bit much there? If using semver or similar you are fine to break the API at a major release point, that is what a major release means, though it would be preferable for you to not immediately stop all support for the previous major version. > What if we intentionally made deprecated functions return the wrong result … sometimes? Hell no. A complete break is far preferable. Making your entire API essentially a collection of undefined (or vaguely undefined) behaviours is basically evil. You effectively render all other projects that have yours as a dependency, also just collections of vaguely defined behaviours. If your API isn't set in stone, say so then people have nothing to complain about unless they specifically ask you to keep something stable (and by “ask you to keep something stable” I mean “offer to pay for your support in that matter”). > Users that are very sensitive to the correctness of the results… That is: any user with any sense. > might want to swap the wrong result for an artificial delay instead. That is definitely more palatable. A very short delay to start with, getting longer until final deprecation. How short/long is going to be very dependent on use case and might be very difficult to judge: the shortest needs to be long enough to be noticeable to someone paying attention and testing between updating dependencies and releasing, but short enough that it doesn't completely break anything if someone updates and releases quickly, perhaps to bring in a bugfix that has begun to affect their project. This is still evil, IMO, but a much lesser evil. I'd still prefer the complete break, but then again I'm the sort of person who would pay attention to deprecation notices, so unless you are a hidden nested dependency I'd not be affected.

Lvl999Noob 11mo ago

The various projects that say something is deprecated but then don't give a removal timeline or keep delaying the removal (or even explicitly say it won't be removed, just remain deprecated) are the cause of this problem. IMO, any deprecation should go in the following steps: 1. Decide that you want to deprecate the thing. This also includes steps on how to migrate away from the thing, what to use instead, and how to keep the existing behaviour if needed. This step would also decide on the overall timeline, starting with the decision and ending with the removal. 2. Make the code give out big warnings for the deprecation. If there's a standard build system, it should have support for deprecation warnings. 3. Break the build in an easy to fix way. If there is too much red tape to take one of the recommended steps, the old API is still there, just under a `deprecated` flag or path. Importantly, this means that at this step, 'fixing' the build doesn't require any change in dependencies or (big) change in code. This should be a one line change to make it work. 4. Remove the deprecated thing. This step is NOT optional! Actually remove it. Keep it part of your compiler / library / etc in a way to give an error but still delete it. Fixing the build now requires some custom code or extra dependency. It is no longer a trivial fix (as trivial as the previous step at least). Honestly, the build system should provide the tools for this. Being able to say that some item is deprecated and should warn or it is deprecated and should only be accessible if a flag is set or it is removed and the error message should say "function foo() was removed in v1.4.5. Refer to the following link:..." instead of just "function foo() not found" If the build system has the option to treat warnings as errors, it should also have the option to ignore specific warnings from being treated as such (so that package updates can still happen while CI keeps getting the warning). The warning itself shouldn't be ignored.

shadowgovt 11mo ago

Well written, but author is at the risk of tripping over Poe's Law, especially if readers don't read to the bottom. Author's point is that their modest proposal (and its sibling, introducing intentional delays in resolving the deprecated API pieces) is a bad idea. Instead, author suggests that making the API change at all is begging the question "Who does this API serve?" It is, perhaps, okay actually if the old system never gets deprecated.

mxey 11mo ago
> especially if readers don't read to the bottom. That note at the bottom was only added after the article was posted.

kazinator 11mo ago

Deprecation warnings are precisely that --- warnings --- so that people have the option not to act on them. So, it is of little surprise that users exercise one of the two available use case scenarios, which is not acting. There are sophisticated users who care about the quality of their code and care about it breaking as infrequently as possible. Those users follow warnings. Not only warnings that happen by default; they use additional tooling to get extra warnings. The follow up on warnings. Deprecation warnings serve those people. As for the others, who cares. "We generously told you this would be removed, for years". People who ignore warnings related to compatibility and have a workflow whereby your dependencies are not pinned down to specific versions, in some project configuration file, so that they are always getting the latest dependencies, are choosing to inflict breakages on themselves.

burnt-resistor 11mo ago

Code churn is an evil, negative value activity. Design sanely and carefully before settling upon a published, standard contract. Churn of external-facing APIs should be extremely rare to solve essential critical problems, not for pseudo-maintenance bikeshedding. Also, the "it's a hobby" excuse doesn't fly. tl;dr: Stop changing and breaking shit unnecessarily.

nitwit005 11mo ago

I found the referenced article linked at the top interesting: https://sethmlarson.dev/deprecations-via-warnings-dont-work-for-python-libraries https://sethmlarson.dev/deprecations-via-warnings-dont-work-... The underlying complaint seems to be about libraries, rather than user behavior.

eslaught 11mo ago

The solution I've found is to make using the API a hard error with an explicitly temporary and obnoxiously-named workaround variable. WORKAROUND_URLLIB3_HEADER_DEPRECATION_THIS_IS_A_TEMPORARY_FIX_CHANGE_YOUR_CODE=1 python3 ... It's loud, there's an out if you need your code working right now, and when you finally act on the deprecation, if anyone complains, they don't really have legs to stand on. Of course you can layer it with warnings as a first stage, but ultimately it's either this or remove the code outright (or never remove it and put up with whatever burden that imposes).

tennysont 11mo ago
I heard a second-hand story about some team at Google who did this, and named the variable something like: I_ACKNOWLEDGE_THAT_THIS_CODE_WILL_PERMANENTLY_BREAK_ON_2022_09_20_WITHOUT_SUPPORT_FROM_TEAM_X=1 a year before the deadline. I would be mildly amused by adding _AND_MY_USER_ID_IS="<user_id>"
pvtmert 11mo ago
Love this idea, as it is already implemented in a $FAANG company tool. (used company wide by 80k+ SDEs). I got used to seeing these in the logs and terminal. So much that my brain now automatically ignores it from my view/seeing like it does for my nose.

lisper 11mo ago

> The response.getheader method in urllib has been deprecated since 2023 because the response.headers dictionary is what should be used instead. Then response.getheader should just do that. There is no reason to expose the implementation to the user unless performance is critical.

JaggerJo 11mo ago

Thats madness. Just remove deprecated functions after a reasonable time period.

phyzome 11mo ago

« When the method was eventually removed, lots of code broke. » Well, removing it earlier would just mean that lots of code would break earlier...

deleted 11mo ago

[deleted]

RonanSoleste 11mo ago

Never do this on the job. Its called corporate sabotage and will result in a lot of trouble for you. Its also a generally bad idea. The whole point of deprecation is to let others choose a moment to switch over on their own moment of choosing. If you don't want to maintain it just remove it. It is far nicer behavior. Don't force others in a debugging hell. It makes you a bad person.

npunt 11mo ago

Filed under: trying to solve another domain's problem with only the tools in your domain (this is almost always a bad idea)

mamcx 11mo ago

The sentiment is good but the solution is wrong. The ideal flow, IMHO: 1: Emit warning, and include if possible a deadline ("will be removed in the next major version") 2: After X time, BEFORE the deadline, turn it into a compiler OR linter error, but keep the code 3: Do the appropriated notification in the channels about it of impending doom 4: Doom If this is done correctly, we change the expectations from "warnings LOL!" to "warnings are serious business" that is missing in a lot of contexts

hacker_homie 11mo ago

Make the deprecated method slower with a function from the deprecation release so the longer it goes on until it gets to around a day. then remove the function.

asveikau 11mo ago

> The response.getheader method in urllib has been deprecated since 2023 because the response.headers dictionary is what should be used instead. Who cares? This is such a trivial example, where there is no maintenance cost associated with leaving a dummy method in that does a dictionary lookup. I understand there are times when maintenance costs are substantial, but it's hard to take someone seriously when this is their example. The obsession with newness, and stigmatizing something that doesn't conform to your sense of chasing newness, is really silly.. can you believe it's been deprecated since 2023 and someone still uses it???? 2023 was not some kind of dark ages of distant history.

tennysont 11mo ago

(Notwithstanding that this is a joke) Maybe it's just me, but I read this as a solution that would be implemented internally at a large company to distribute pain/accountability/tech-debt across time to a team which might have high turnover. i.e., a way to align incentives by punishing teams with bombs (via their metrics) in their code, before the bomb actually detonates.

pvtmert 11mo ago

I have 2 better ideas; 1. Start charging money for/of deprecated APIs. Just like Oracle did it with Java 8. - OR - 2. Add a timestamp-based RuntimeException to the very same code-path. If the date is greater than (>) the deprecation date, simply throw RuntimeException. for 100% of the requests, all the time. Yes, it will page someone, and yes, it will get fixed immediately!

sshine 11mo ago

For one customer I do maintenance on a piece of software. Building it produces about two-three dozen deprecation warnings. The whole software stack relies on a cluster of packages that stopped receiving updates 5 years ago. The software is not facing end-users. But it does build using NPM and not via vendored packages. To avoid those warnings, large parts of the code need to be rewritten using a different set of packages. That doesn't get prioritised because it works. The software sucks in many ways, but only from the perspective of an artisan. The customer is happy to ignore warnings as long as the software does its job. There isn't money in fixing things that work because it got old. The incentives for the people putting the deprecation warnings in those packages don't align with the users of those packages. Their timelines and motives are different.

shomp 11mo ago

How about never deprecate

neckardt 11mo ago

I thought the industry solved this by bundling breaking changes in major version updates. V 1.0 - foo introduced V 1.1 - foo deprecated, recommend bar V 2.0 - foo removed, only bar Users can stay on 1.x indefinitely, even if it never receives updates. Development continues on 2.x, eventually 3.x and so on. Users only experience breaking changes when they manually do a major version upgrade.

dJLcnYfsE3 11mo ago

In a bit roundabout way Java 11 added `forRemoval` attribute to `@Deprecated` annotation so developers could indicate they really mean it.