Feature updates guide: history, examples and current context

Most writing about product changes covers arrivals. The changes that actually hurt are departures: the field that stops being returned, the export that loses a column, the option that quietly disappears from a menu. Removal is the part of the update stream that has a deadline attached, and it is the part almost nobody has a process for. This page is about handling a removal before it happens to you.

What to take away

• Deprecated, frozen, sunset and removed are four states with four different obligations, and they are routinely used as if they were one word.
• Your exposure is not the number of things you use. It is the number of things you use that you could not replace within the notice period.
• The work that saves you is done before any announcement: an inventory of what you depend on, written down, with an owner.

The four states, kept apart

State	What it means	What is still true	What you should be doing
Deprecated	Officially discouraged, still working	It works exactly as before	Stop building anything new on it
Frozen	No further changes, still supported	Bugs may not be fixed	Plan the replacement, do not start it yet
Sunset announced	An end date exists	It works until that date	Execute the migration you already planned
Removed	Gone	Nothing	Recover, and learn why you were surprised

The distinction matters because the states carry different urgency and people collapse them in both directions. Treating a deprecation as an emergency wastes a quarter. Treating a sunset announcement as a deprecation loses the product. The word deprecation is doing a lot of quiet work in that table, and it is the one most often read as "it is going away next month" when it means nothing of the kind.

Why the notice period is never as long as it looks

An announced end date is not the date you have. Subtract three things from it.

Subtract discovery. If you learn about the change three weeks after it is published, those weeks are gone. Nothing about the announcement is addressed to you personally.

Subtract the freeze you cannot control. If the replacement is itself new, it will have its own defects during the first weeks, and building against a moving target costs more than building against a settled one.

Subtract everything downstream. A change to one field propagates to whatever reads that field: reports, dashboards, a spreadsheet somebody built two years ago, an automation nobody remembers. The reason a small change becomes a large project is almost always the third item, and the reason for that is that no inventory exists.

The dependency inventory

This is the whole of the preparation, and it is boring, which is why it does not get done. Write down, in one place, every external thing your operation relies on to work. For each entry, four fields are enough:

• What it is, in the operator's own vocabulary rather than yours.
• What breaks if it disappears tomorrow, named specifically.
• How long a replacement would take, guessed honestly and marked as a guess.
• Who is responsible for noticing an announcement about it.

The fourth field is the one that changes outcomes. An inventory with no owner per row is a document; an inventory with owners is a monitoring system. The general shape of a change register covers what to record about changes once they arrive, and the inventory is the thing that tells you which of those changes are yours.

Compatibility promises, and how much to believe

Some operators publish a compatibility policy: a statement about what they will and will not break, and with how much warning. This is worth reading closely, because it is the only part of the relationship with any structure to it. What you are looking for is whether the promise is tied to a version scheme, whether the notice period is stated as a duration, and what is explicitly excluded from the promise.

Two ideas make the policy legible. Backward compatibility is the property being promised: old callers keep working against a newer version. Software versioning is the notation the promise is written in, which is why a scheme that signals breaking changes in the version number is more informative than one that does not.

Neither tells you what will actually happen. A published policy is a commitment the operator has made in public, and the reasons an operator's own document is the only citable source about their product apply here exactly as they do to ranking.

When the removal lands anyway

Some removals arrive without usable notice, and there is no process that prevents that. What a process can do is shorten the gap between the removal and your understanding of what it broke. That means knowing what your normal looks like well enough to see the deviation, which is the same instrumentation problem as telling an outage apart from a change in your own numbers. Security guidance from CISA on why patches and updates arrive when they do is a useful reminder that not every forced change is a product decision; some of them are not optional for the operator either.

Afterward, the question worth asking is not how to prevent the next one. It is why this one was a surprise, which almost always resolves to a missing row in an inventory nobody kept. The wider question of where a dependency concentrates your risk is the same exposure seen from the other side.

Common questions

How far ahead should I plan for something that is only deprecated?

Far enough to know the answer, not far enough to have built it. Write down what the replacement would be and roughly what it would cost. Stop there until an end date exists, because a deprecated thing can sit unchanged for years and the plan will be stale by then anyway.

Is there a way to find out about removals earlier?

Only by watching the places the operator publishes and by using what you use often enough to notice a warning. There is no reliable alert service for this, and anything claiming to be one is aggregating the same public pages you could read.

What if a replacement does not exist yet?

Then the honest answer is that you are exposed and cannot fix it by planning. Record it as exposure, decide whether the risk is tolerable, and revisit on a fixed date rather than on a feeling.

Should I avoid new features to reduce this problem?

Not as a rule, but the exposure is real and should be priced in. A newer thing has a shorter track record and a higher chance of being withdrawn, which is worth something in the decision even when the feature is genuinely better. The durability tests that separate a lasting change from a passing one are worth applying before you commit to it.