Breaking Change

Software is constantly being developed further. Most of the time, users barely notice: there are new features, and everything old keeps working. But sometimes developers change something so fundamentally that other people’s programs break as a result. That’s exactly what a breaking change is. The English term has also become established in German. Typical examples: a command gets renamed, a function disappears, or a result is suddenly returned in a different format.

Why a renamed command costs companies money

Modern software is rarely built from scratch. Almost every program uses ready-made building blocks from other developers. An app displays a map, but the map comes from Google. An online shop converts prices, but the exchange rates come from a bank. Such building blocks often stack dozens of layers deep.

If someone changes something fundamental at the very bottom of the stack, everything above it wobbles. A single renamed command can bring thousands of programs to a halt. The affected companies then have to assign developers to adapt their own code. This costs time nobody planned for, and doesn’t add a single new feature.

That’s why a breaking change is considered something not to be made lightly. Anyone with a large user base prefers to collect such changes and release them in bundles. A well-known example is the programming language Python: the jump from version 2 to 3 deliberately broke with old rules. The transition dragged on for more than ten years.

Version numbers as a warning signal

So that no one gets caught off guard, there’s a widespread rule for version numbers. It’s called Semantic Versioning and consists of three numbers, for example 4.2.1. The last number increases with bug fixes, the middle one with new features. The first number only jumps when something old stops working.

A jump from 4.2.1 to 5.0.0 is therefore a warning. It means: check your code before you update. A jump to 4.3.0, on the other hand, can usually be adopted without worry. That’s why many companies let their systems install minor updates automatically, but only apply major ones after manual review.

A second tool is so-called deprecation. A command is marked as outdated but keeps working for a while longer. Developers see a warning message in the meantime. Only months or years later is it actually removed. This spreads the effort out over a longer period.

AI models that get shut down

The term currently comes up especially often in the AI industry. Providers like OpenAI, Anthropic, or Google make their models available via so-called interfaces. An interface is a fixed address to which a program sends a question and gets back an answer. Companies build their products on top of this without operating a model themselves.

If an old model gets shut down, that’s a classic breaking change. The provider announces a shutdown date, after which the address no longer responds. All customers have to switch to a newer model. This becomes tricky because the new model is usually better, but answers differently. Carefully crafted prompts can then suddenly produce useless results.

A common misconception is that every deterioration counts as a breaking change. Strictly speaking, what’s meant is only the breach of a promise: something that, according to the documentation, should work no longer does. If an app gets slower, that’s annoying, but technically not a breaking change. If you read about a “deprecation schedule” in tech news, this is exactly the topic being addressed.