4 ms·
The secret trick I've used on rare occasion, but when necessary, is the "ten second rule." Users don't notice a deprecation warning. But they might notice addi
by shadowgovt 10mo ago
The secret trick I've used on rare occasion, but when necessary, is the "ten second rule."
Users don't notice a deprecation warning. But they might notice adding a "time.sleep(10)" immediately at the top of the function. And that gives them one last grace period to change out their software before it breaks-breaks.
- odie5533 10mo agoThis will just waste CI compute and not solve anything.
- shadowgovt 10mo agoIt's worked in the past. But it does require someone at your org to care that CI times are spiking, which is not always a thing you can rely upon. In addition: if CI is the only place the issue shows up, and never in a user interaction... Why does that software exist in the first place? In that context, the slowdown may be serving as a useful signal to the project to drop the entire dependency. ETA: To be clear, I don't do this as a substitute for a regular deprecation cycle (clear documentation, clear language-supported warnings / annotations, clear timeline to deprecate); I do it in addition before the final yank that actually breaks end-users.
- odie5533 10mo agoMost CI runs I see have more than a 10s variance.
- pavel_lishin 10mo agoAre you saying you wouldn't notice if your CI suddenly started taking twice as long, ten times as long, a hundred times as long to run?
- minitech 10mo agoThis is so much worse than just making the breaking change.
- shadowgovt 10mo agoIt depends on how we define "worse." A breaking change causes a full-stop to a service. An intentional slowdown lets the service continue to operate at degraded performance. I concur that it's less clear for debugging purposes (although any reasonable debugging infrastructure should allow you to break and see what function you're in when the program hangs; definitely not as clear as the program crashing because the called function is gone, however).
- minitech 10mo agoA breaking change in a dependency doesn’t cause a full-stop to a service at all. The old version continues to work. Making subtly harmful changes so that new broken versions sneak in is just a bad idea and totally unnecessary.
- shadowgovt 10mo ago> A breaking change in a dependency doesn’t cause a full-stop to a service at all From the article: "We still received feedback from users that this removal was unexpected and was breaking dependent libraries." I think we may be assuming different floors on service maintainer competency; with so many users pulling in dependencies across an arbitrarily-wide version window with no testing, such changes do break services.
- minitech 10mo agoIt’s not necessary to cater to the absolute least competent end user to begin with, but inserting slowdown bugs does not even achieve that. (Note that the bit about the breaking of dependent libraries you’re quoting is still not actually a service being affected.)
- somat 10mo agoJust break, then revert when anyone complains, on every single release. eventually you will get a release where nobody complains as they move off the depreciated api due to breakage annoyance.
- tgsovlerkhgsel 10mo agoI think it's more likely that they move off the broken library due to breakage annoyance.