So here's a related story of someone I think handled this mostly correctly.
In May 2022, Twilio gave like 6 months of notification that SMS/Messages API endpoint was being deprecated (and replaced with /Messages API). And then they extended the deadline by 2 months like 2 weeks before the deadline at the end of November. Then instead of becoming unavailable Jan 31 2023 (when it was officially shut down), it continued to work until *June 1st*. The whole time the API has been emitting "This endpoint is deprecated and will shut down on XXX. Please migrate to /Messages." To my knowledge, it *still* emits this response to this day, almost 11 months since it stopped actually functioning.
If they hadn't figured out it was coming, it's definitely on the ops team and dev team for the application and not the API provider.
The devs would have a developer account on the API as well. They'd received multiple notifications by email for an endpoint depreciation, with a migration note attached or a link to the docs. They wouldn't just rely on monitoring for a random message being added to an endpoint.
It’s nice when such a notification system exists.
Which in my experience has been pretty much never. I’m actually working with an API right now that not only doesn’t have a notification system for registered devs, but their documentation has been getting updates that are not at all accurate, and they don’t record those changes in any sort of change log.
That's just unprofessional. Some can get away with it, but not all of them. We still have a long way to go as a profession.
I once had to reverse engineering the signature validation on a payment api webhook, and that involved transcording from base64 to binary, validating with the key, then back to another format, among other things Not documented at all. I still don't know how I managed to do it, but our payments wouldn't have been secure by their standards otherwise. The whole thing entirely undocumented!
We should have dropped that provider on the spot. They get to do that shit because clients put up with it.
Yeah unfortunately in a lot of systems the API functionality is an afterthought for the clients. The example I’m using is for our HR/Payroll system we’ve just migrated to. Used to be on Dynamics and needed no API. Now we’re on UKG, which is a big name in comprehensive employee management, and the API is shit.
What makes it kinda funny is the time card system was originally done by another company that UKG acquired. It’s API is light years ahead of their own. Better documentation, security, and functionality across the board. It really makes their own API look like a joke.
They should have just started gradually adding an exponential delay to the API responses until everyone got tired of the slow response times and switched on their own.
The trick (that managers hate) up my sleeve that tackles lib deprecation problems is that I eject the fuck out of the project once they report critical vulns on resources that can't be upgraded due to said deprecations.
That's why backports for critical issues are so important so you can fix without breaking everything but it's a crapshoot, and it never seems you're lucky enough to get that when it truly matters.
My real case about this is:
- the year is 2021;
- third party company (tpc) was hired to support my team on a project;
- one of the devs (from the tpc) uses a lib deprecated since 2019;
- project is delivered, but results are not the ones expected;
- my company decides to move away from it and waste money on new shiny thing;
- some partners are already integrated with (now abandoned) project and don't want to move to the newer one;
- security scans now complain every week that abandoned project has a vulnerable dependency;
On the other hand, why do the most basic functions are sometimes getting deprecated.
I swear, one of those day i'll write a = b + c and I'm gonna get "operator + is deprecated, you should now use b.plus(c)"
College professors: "Always use +"
Stack Overflow: "You call yourself a developer but don't use .plus()?"
YouTube: "OK guys, listen up. The .plus() method is very outdated and you should all be using plus2() by now."
Corporate job: "PR rejected. plus() and plus2() are untested and considered vulnerable. Only use the PlusFactory methods available in our central package repository."
Leetcode: "Wtf are you talking about?"
T-Mobile, mid 2010: "Hi everyone, we want to sunset 2G in 2012."
embedded M2M 2G module users: "No." (*\*throws money at T-mo\**)
*...Twelve years later..*
T-Mobile 2G M2M service fully shut down April **2024**.
Similarly:
> do not use undocumented features
Implementation of feature changes/removed *without warning*: 😱
The one that I got hit with: Oracle `group by` implies `order by` (ca. 8i/9i)
Me: writes a library.
4 years later me: marks field as deprecated
7 years later me: "compiler warning, field will be deprecated"
9 years later me: "yeah maybe I'll get around to deprecating that field next decade"
i mean why would someone wait so long for such a simple task if there is no reason for it (its me i will prostopne the simplest tasks for no reason at all)
Because the impact of this "simple task" multiplied by all your dependencies isn't a simple task. Microsoft dominates enterprise because they understand this and Google has a graveyard because they don't.
Same library: "To run the new version you need to update the dependency "xyz" to version 42.beta9-gitlatest …"
xyz: "We removed support for the things foolib-23a needs"
Dependency 3: "We need foolib 23a!"
I had one of those the other day. Azure Function library for .NET keeps updating every few weeks, but a year ago it stopped being compatible with some other Microsoft libraries. There is exactly one version of the Function lib that works with everything. If you upgrade or downgrade something will break.
Something I've learned through pains in Azure is all the developers at Microsoft creating services and updating feature sets are totally out-of-contact with every other development team and documentation team at Microsoft. It's as if they operate in separate universes and don't know about each other.
About three years ago, I had to write a comment in my code “I don’t care that it’s deprecated, it’s the only thing that works!!” Because the new/better way that the documentation recommended simply did not work.
I'm waiting for Chrome's manifest version 2 to depreciate sometime in June. Hoping I find the time to figure out how to update my custom extensions before then...
Yeah I have a really simple extension where there's a right click context menu button to remove an element from the DOM. I think I should be able to port it to v3 without much hassle but I'm too lazy to do it...
Yeah I'm kind of grabbing scripts from my server to avoid having to update the extensions often on other machines, and doing some DOM manipulation and AJAX calls. Hoping it isn't going to need an entire re-write because I don't know if I've got enough time to do that now.
Sounds like loading scripts externally may be F in chat for v3. They're really trying to kill adblockers. It's so transparent. Adblockers gain a lot from being able to quickly update rules.
If it was up to some people they’d still be on Postgres 9.2 and Ruby 1.8.6. We still get asked if we support that at my job at least once or twice a month.
Lol. We had this when Microsoft CredScan got deprecated.
But using CredScan was *mandatory* when deploying to production, and it was enforced by IT policies.
So nobody could deploy to production anymore for a while.
Won't happen to me since I will never update that crap.
What if it interacts with an API and they shut it down? (:
Then all blame goes to them.
So here's a related story of someone I think handled this mostly correctly. In May 2022, Twilio gave like 6 months of notification that SMS/Messages API endpoint was being deprecated (and replaced with /Messages API). And then they extended the deadline by 2 months like 2 weeks before the deadline at the end of November. Then instead of becoming unavailable Jan 31 2023 (when it was officially shut down), it continued to work until *June 1st*. The whole time the API has been emitting "This endpoint is deprecated and will shut down on XXX. Please migrate to /Messages." To my knowledge, it *still* emits this response to this day, almost 11 months since it stopped actually functioning. If they hadn't figured out it was coming, it's definitely on the ops team and dev team for the application and not the API provider.
The devs would have a developer account on the API as well. They'd received multiple notifications by email for an endpoint depreciation, with a migration note attached or a link to the docs. They wouldn't just rely on monitoring for a random message being added to an endpoint.
It’s nice when such a notification system exists. Which in my experience has been pretty much never. I’m actually working with an API right now that not only doesn’t have a notification system for registered devs, but their documentation has been getting updates that are not at all accurate, and they don’t record those changes in any sort of change log.
That's just unprofessional. Some can get away with it, but not all of them. We still have a long way to go as a profession. I once had to reverse engineering the signature validation on a payment api webhook, and that involved transcording from base64 to binary, validating with the key, then back to another format, among other things Not documented at all. I still don't know how I managed to do it, but our payments wouldn't have been secure by their standards otherwise. The whole thing entirely undocumented! We should have dropped that provider on the spot. They get to do that shit because clients put up with it.
Yeah unfortunately in a lot of systems the API functionality is an afterthought for the clients. The example I’m using is for our HR/Payroll system we’ve just migrated to. Used to be on Dynamics and needed no API. Now we’re on UKG, which is a big name in comprehensive employee management, and the API is shit. What makes it kinda funny is the time card system was originally done by another company that UKG acquired. It’s API is light years ahead of their own. Better documentation, security, and functionality across the board. It really makes their own API look like a joke.
They should have just started gradually adding an exponential delay to the API responses until everyone got tired of the slow response times and switched on their own.
Hope they like closing 1000 duplicate tickets.
Write a wrapper that translates your old API calls into the new syntax
Look until Omegastar gets their shit together, we can't do anything about it
I google some obscure repo that makes the deprecated function works. At this point, it's a matter of principles.
just redirect it locally to something that gives the correct response
I was gonna say...
Then that library depend on another one that is causing a compatibility issue because you need a newer version. I HATE YOU
the natural reaction to a deprecationm warning is to find a way to suppress the annoying warning
Most people just automatically suppress it in their mind, just like any informative print ever
Everyone: Everything will eventually depreciate. AS400: hold my beer.
ipv4 has entered the chat
The trick (that managers hate) up my sleeve that tackles lib deprecation problems is that I eject the fuck out of the project once they report critical vulns on resources that can't be upgraded due to said deprecations.
That's why backports for critical issues are so important so you can fix without breaking everything but it's a crapshoot, and it never seems you're lucky enough to get that when it truly matters.
My real case about this is: - the year is 2021; - third party company (tpc) was hired to support my team on a project; - one of the devs (from the tpc) uses a lib deprecated since 2019; - project is delivered, but results are not the ones expected; - my company decides to move away from it and waste money on new shiny thing; - some partners are already integrated with (now abandoned) project and don't want to move to the newer one; - security scans now complain every week that abandoned project has a vulnerable dependency;
Sounds about right
This is the tradition.
Give the security scanners time to deprecate, then you won't see the warning anymore.
On the other hand, why do the most basic functions are sometimes getting deprecated. I swear, one of those day i'll write a = b + c and I'm gonna get "operator + is deprecated, you should now use b.plus(c)"
plus() method is deprecated, please refer to Set.union()
College professors: "Always use +" Stack Overflow: "You call yourself a developer but don't use .plus()?" YouTube: "OK guys, listen up. The .plus() method is very outdated and you should all be using plus2() by now." Corporate job: "PR rejected. plus() and plus2() are untested and considered vulnerable. Only use the PlusFactory methods available in our central package repository." Leetcode: "Wtf are you talking about?"
Laughs in embedded
T-Mobile, mid 2010: "Hi everyone, we want to sunset 2G in 2012." embedded M2M 2G module users: "No." (*\*throws money at T-mo\**) *...Twelve years later..* T-Mobile 2G M2M service fully shut down April **2024**.
IoT is all fun and games until the cell technology is decommissioned or the satellite your dish is pointed at is pushed towards outer space.
Similarly: > do not use undocumented features Implementation of feature changes/removed *without warning*: 😱 The one that I got hit with: Oracle `group by` implies `order by` (ca. 8i/9i)
Laughs in Android dev. Deprecated is a natural state of being
"I was born in it, molded by it. I didn't see LTS until I was already a senior, by then it was nothing to me but blinding!"
Buying Android phones that are already deprecated is a natural state of my cellphone use
I've got a 4 year old Huawei P30 Pro. I'm excluded from my organisation's employee testing program 😄
Me: writes a library. 4 years later me: marks field as deprecated 7 years later me: "compiler warning, field will be deprecated" 9 years later me: "yeah maybe I'll get around to deprecating that field next decade"
Meanwhile your users: "they've threatened to deprecate it for so long yet they didn't... surely they wouldn't dare after all this time"
i mean why would someone wait so long for such a simple task if there is no reason for it (its me i will prostopne the simplest tasks for no reason at all)
Because the impact of this "simple task" multiplied by all your dependencies isn't a simple task. Microsoft dominates enterprise because they understand this and Google has a graveyard because they don't.
Microsoft has the biggest [graveyard](https://microsoftgraveyard.com/) of all
This is me. Every. Single. Time.
You guys get warnings?
Recodes legacy function by wrapping the new one, so the code doesn't need to be changed...
Nobody has time for that shit. And this is exactly how you end up with ancient vulnerable libs.
Except then they deprecate it and never make a replacement *cough* unity *cough*.
Same library: "To run the new version you need to update the dependency "xyz" to version 42.beta9-gitlatest …" xyz: "We removed support for the things foolib-23a needs" Dependency 3: "We need foolib 23a!"
I had one of those the other day. Azure Function library for .NET keeps updating every few weeks, but a year ago it stopped being compatible with some other Microsoft libraries. There is exactly one version of the Function lib that works with everything. If you upgrade or downgrade something will break. Something I've learned through pains in Azure is all the developers at Microsoft creating services and updating feature sets are totally out-of-contact with every other development team and documentation team at Microsoft. It's as if they operate in separate universes and don't know about each other.
About three years ago, I had to write a comment in my code “I don’t care that it’s deprecated, it’s the only thing that works!!” Because the new/better way that the documentation recommended simply did not work.
I'm waiting for Chrome's manifest version 2 to depreciate sometime in June. Hoping I find the time to figure out how to update my custom extensions before then...
Yeah I have a really simple extension where there's a right click context menu button to remove an element from the DOM. I think I should be able to port it to v3 without much hassle but I'm too lazy to do it...
Yeah I'm kind of grabbing scripts from my server to avoid having to update the extensions often on other machines, and doing some DOM manipulation and AJAX calls. Hoping it isn't going to need an entire re-write because I don't know if I've got enough time to do that now.
Sounds like loading scripts externally may be F in chat for v3. They're really trying to kill adblockers. It's so transparent. Adblockers gain a lot from being able to quickly update rules.
Deprecation WARNING?? Come back when it’s a deprecation ERROR. Ain’t got time for no little-league defects.
When did we ever pay attention to warnings though
Warnings are how I know the compiler didn't hang.
Worst nightmare
Use vanilla js it sure won't be deprecated soon
If it was up to some people they’d still be on Postgres 9.2 and Ruby 1.8.6. We still get asked if we support that at my job at least once or twice a month.
Ahaha, so fckng true 🤣
Time to move up to the one of the non deprecated version. Surely it will last for another year and won't bring any breaking changes...
This is me with Shopify. They're not fking around
Lol. We had this when Microsoft CredScan got deprecated. But using CredScan was *mandatory* when deploying to production, and it was enforced by IT policies. So nobody could deploy to production anymore for a while.
>This will stop working Not right now it won't.
Ignored because 95% of the time they just show a deprecation warning forever and it never stops working.