To be clear, there's no reason why you can't update dependencies in advance of a cooldown period. The cooldown is an enforced policy that you can choose to override as needed.

(This also doesn't apply to vulnerabilities per se, since known vulnerabilities typically aren't evaluated against cooldowns by tools like Dependabot.)

▲

jcalvinowens 9 hours ago | parent [-]

No you can't, the cooldown period is started by the new upstream release. So if you follow this "rule" you're guaranteed to be behind the latest upstream release.

▲

woodruffw 9 hours ago | parent [-]

I don't understand what you mean. The cooldown period is something you decide to enforce; you can always override it. It's your prerogative as a responsible engineer to decide the boundaries of policy enforcement.

▲

jcalvinowens 8 hours ago | parent [-]

I mean, you can do anything you want. But you're inventing a new definition of "cooldown" different than TFA...

▲

woodruffw 8 hours ago | parent [-]

I wrote TFA, so I can ensure you that this is what I meant :-)

(Can you say more about what you found unclear in the post? The post definitely does not say "thou shall not update before the cooldown," the argument was that cooldowns are a great default. Engineers are fundamentally always expected to exercise discretion because, per the post, there's no single, sound, perfect solution to supply chain risks.)

▲

jcalvinowens 8 hours ago | parent [-]

> A “cooldown” is exactly what it sounds like: a window of time between when a dependency is published and when it’s considered suitable for use.

^ This is what you wrote. I don't understand how that could possibly be interpreted any other way than I wrote above: an enforced delay on deploying the new code after upstream releases it.

> The post definitely does not say "thou shall not update before the cooldown," the argument was that cooldowns are a great default

Sorry, that is such a cop out. "I didn't actually mean you should do this, I mean you should consider if you should maybe do this and you are free to decide not to and don't argue with me if you disagree every case is different". Either take a stand or don't.

▲

woodruffw 8 hours ago | parent [-]

I think this is an overly tendentious reading. Nobody else seems to have gotten hung up on this, because they understand that it's a policy, not an immutable law of nature.

The argument advanced in the post is IMO clear: cooldowns are a sensible default to have, and empirically seem to be effective at mitigating the risk of compromised dependencies. I thought I took sufficient pains to be clear that they're not a panacea.

▲

jcalvinowens 7 hours ago | parent [-]

I'm simply saying I think the policy you're proposing is bad. It is completely bizarre to me you're trying to frame that as a semantic argument.

▲

woodruffw 7 hours ago | parent [-]

I'm not saying it's a semantic argument. I'm saying that the policy isn't universal, whereas your argument appears to hinge on me thinking that it is. But this seems to have run its course.

	▲	jcalvinowens 7 hours ago \| parent [-]
		That's a semantic argument. Me saying your proposed policy is bad is in no way predicated on any assumption you intended it to be "universal". Quite the opposite: the last thing anybody needs at work is yet another poorly justified bullshit policy they have to constantly request an "exception" to to do their job...