Serguey Asael Shinder: A deprecation with a date is a scheduling problem you will get wrong
GitHub marked the all-platform CodeQL bundle deprecated this week and named the removal date: mid-March 2027. Download the platform-specific bundle instead. Nothing breaks today.
That last sentence is the whole problem.
A deprecation notice has two numbers — how much work it is, and how long you have — and human teams handle the first one fine. It is the second that defeats us, because a long deadline does not produce early action, it produces no action. Eighteen months is past the horizon of any sprint, any quarter, and most people's tenure on the team. The work does not get scheduled because there is no meeting at which it is the most urgent thing, and there never will be until the week it breaks.
Then it breaks everywhere at once. That is the specific cruelty of this class of change. A pinned URL in a workflow file does not degrade; it returns 200 until the day it returns 404, and if the same URL is pinned in fourteen repositories, you get fourteen red pipelines in the same hour, on a morning you had planned to do something else.
So the discipline is not "remember to do it". Memory is what already failed.
Do the grep on the day you read the notice. Not the migration — the inventory. How many places reference the thing that is going away? That question takes four minutes and its answer determines whether this is a ticket or a project, and you will never have a cheaper moment to ask it.
Then write the ticket with the vendor's date in the title, not "soon", not "before it breaks". A date in a title is the only form of this information that survives a backlog grooming session, because it is the only form that can be sorted.
And prefer the change that removes the deadline over the change that meets it. In the CodeQL case there is a detail that tells you which is which: Linux ARM64 binaries were never in the all-platform bundle at all. Anyone who moved runners to ARM already hit this and solved it by hand. That is the tell — the "convenient" single artefact had already stopped covering the real fleet, and the deprecation is catching up with a decision the platform made earlier.
The general form: when a vendor removes the convenient option, check whether it was still convenient. Often the aggregate thing you are attached to had already quietly stopped matching what you deploy, and you were pinned to it out of habit rather than fit. Those migrations are the cheap ones, and they are also the ones most likely to be postponed, because a thing that still works looks like a thing that is fine.
The deadline is not the risk. The uniformity of the failure is the risk, and the only defence against it is knowing the count before you need it.