Breaking Change
Ein Breaking Change ist eine Änderung an einer Software, nach der bisher funktionierende fremde Programme nicht mehr laufen. Solche Änderungen werden meist angekündigt und in großen Versionssprüngen gebündelt, weil alle Nutzer nachbessern müssen.
Software wird ständig weiterentwickelt. Meistens merken die Nutzer davon wenig: Es gibt neue Funktionen, alles Alte läuft weiter. Manchmal ändern die Entwickler aber etwas so grundlegend, dass Programme anderer Leute danach kaputtgehen. Genau das ist ein Breaking Change, wörtlich eine « brechende Änderung ». Der englische Begriff hat sich auch im Deutschen durchgesetzt. Typische Beispiele: Ein Befehl wird umbenannt, eine Funktion verschwindet, oder ein Ergebnis kommt plötzlich in einer anderen Form zurück.
Warum ein umbenannter Befehl Firmen Geld kostet
Moderne Software wird selten von Grund auf neu gebaut. Fast jedes Programm nutzt fertige Bausteine anderer Entwickler. Eine App zeigt eine Karte an, aber die Karte kommt von Google. Ein Onlineshop rechnet Preise um, aber die Wechselkurse liefert eine Bank. Solche Bausteine stapeln sich oft dutzendfach übereinander.
Ändert nun jemand ganz unten im Stapel etwas Grundlegendes, wackelt alles darüber. Ein einziger umbenannter Befehl kann tausende Programme lahmlegen. Die betroffenen Firmen müssen dann Entwickler abstellen, die den eigenen Code anpassen. Das kostet Zeit, die niemand eingeplant hat, und bringt keine einzige neue Funktion.
Deshalb gilt ein Breaking Change als etwas, das man nicht leichtfertig macht. Wer viele Nutzer hat, sammelt solche Änderungen lieber und veröffentlicht sie gebündelt. Ein bekanntes Beispiel ist die Programmiersprache Python: Der Sprung von Version 2 auf 3 brach absichtlich mit alten Regeln. Der Umstieg zog sich über mehr als zehn Jahre hin.
Versionsnummern als Warnsignal
Damit niemand überrascht wird, gibt es eine verbreitete Regel für Versionsnummern. Sie heißt Semantic Versioning und besteht aus drei Zahlen, zum Beispiel 4.2.1. Die letzte Zahl steigt bei Fehlerkorrekturen, die mittlere bei neuen Funktionen. Die erste Zahl springt nur dann, wenn etwas Altes nicht mehr funktioniert.
Ein Sprung von 4.2.1 auf 5.0.0 ist also eine Warnung. Er bedeutet: Prüfe deinen Code, bevor du aktualisierst. Sprünge auf 4.3.0 dagegen kann man meist bedenkenlos übernehmen. Viele Firmen lassen ihre Systeme deshalb kleine Updates automatisch einspielen, große aber nur nach manueller Prüfung.
Ein zweites Werkzeug ist die sogenannte Deprecation, die Abkündigung. Ein Befehl wird als veraltet markiert, funktioniert aber noch eine Weile weiter. Entwickler bekommen dabei eine Warnmeldung angezeigt. Erst Monate oder Jahre später wird er wirklich entfernt. So verteilt sich der Aufwand über einen längeren Zeitraum.
KI-Modelle, die abgeschaltet werden
In der KI-Branche taucht der Begriff derzeit besonders oft auf. Anbieter wie OpenAI, Anthropic oder Google stellen ihre Modelle über sogenannte Schnittstellen bereit. Eine Schnittstelle ist eine feste Adresse, an die ein Programm eine Frage schickt und eine Antwort zurückbekommt. Firmen bauen ihre Produkte darauf auf, ohne selbst ein Modell zu betreiben.
Wird ein altes Modell abgeschaltet, ist das ein klassischer Breaking Change. Der Anbieter kündigt ein Abschaltdatum an, danach antwortet die Adresse nicht mehr. Alle Kunden müssen auf ein neueres Modell umstellen. Heikel wird es, weil das neue Modell zwar meist besser ist, aber anders antwortet. Sorgfältig formulierte Anweisungen liefern dann plötzlich unbrauchbare Ergebnisse.
Ein häufiger Irrtum ist, dass jede Verschlechterung ein Breaking Change sei. Gemeint ist strenger nur der Bruch einer Zusage: Etwas, das laut Dokumentation funktionieren sollte, funktioniert nicht mehr. Wird eine App langsamer, ist das ärgerlich, aber technisch kein Breaking Change. Wenn du in Tech-News von einem « Deprecation-Zeitplan » liest, geht es genau um dieses Thema.