The point is to apply a cooldown to your "dumb" and unaccountable automation, not to your own professional judgment as an engineer.

If there's a bugfix or security patch that applies to how your application uses the dependency, then you review the changes, manually update your version if you feel comfortable with those changes, and accept responsibility for the intervention if it turns out you made a mistake and rushed in some malicious code.

Meanwhile, most of the time, most changes pushed to dependencies are not even in the execution path of any given application that integration with them, and so don't need to be rushed in. And most others are "fixes" for issues that were apparently not presenting an eminent test failure or support crisis for your users and don't warrant being rushed in.

There's not really a downside here, for any software that's actually being actively maintained by a responsible engineer.

▲

jcalvinowens 9 hours ago | parent [-]

You're not thinking about the system dependencies.

> Meanwhile, most of the time, most changes pushed to dependencies are not even in the execution path of any given application that integration with them

Sorry, this is really ignorant. You don't appreciate how much churn their is in things like the kernel and glibc, even in stable branches.

▲

swatcoder 9 hours ago | parent [-]

> You're not thinking about the system dependencies.

You're correct, because it's completely neurotic to worry about phantom bugs that have no actual presence of mind but must absolutely positively be resolved as soon as a candidate fix has been pushed.

If there's a zero day vulnerability that affects your system, which is a rare but real thing, you can be notified and bypass a cooldown system.

Otherwise, you've presumably either adapted your workflow to work around a bug or you never even recognized one was there. Either way, waiting an extra <cooldown> before applying a fix isn't going to harm you, but it will dampen the much more dramatic risk of instability and supply chain vulnerabilities associated with being on the bleeding edge.

▲

jcalvinowens 9 hours ago | parent [-]

> You're correct, because it's completely neurotic to worry about phantom bugs that have no actual presence of mind but must absolutely positively be resolved as soon as a candidate fix has been pushed.

Well, I've made a whole career out of fixing bugs like that. Just because you don't see them doesn't mean they don't exist.

It is shockingly common to see systems bugs that don't trigger for a long time by luck, and then suddenly trigger out of the blue everywhere at once. Typically it's caused by innocuous changes in unrelated code, which is what makes it so nefarious.

The most recent example I can think of was an uninitialized variable in some kernel code: hundreds of devices ran that code reliably for a year, but an innocuous change in the userland application made the device crash on startup almost 100% of the time.

The fix had been in stable for months, they just hadn't bothered to upgrade. If they had upgraded, they'd have never known the bug existed :)

I can tell dozens of stories like that, which is why I feel so strongly about this.

▲

saurik 8 hours ago | parent [-]

If your internal process is willing to ship and deploy upgrades--whether to your code or that of a third party--without testing even so minimally to notice that they cause almost a 100% chance of crashing, you need the advice to slow down your updates more than anyone...

	▲	jcalvinowens 8 hours ago \| parent [-]
		Obviously, they caught the bug and didn't deploy it. The point is that a change to a completely unrelated component caused a latent bug to make the device unusable, ended up delaying a release for weeks and causing them have to pay me a bunch of money to fix it for them. If they'd been applying upgrades, they would have never even known it existed, and all that trouble would have been avoided. I mean, I'm sort of working against my own interest here: arguably I should want people to delay upgrades so I can get paid to backport things for them :)