So erkennst du Breaking Changes in einem Changelog.
Erfasse altes Verhalten, neues Verhalten und angegebene Migration. Nicht jede Release-Notiz ist ein Breaking Change.
Passe den Ablauf an deine Aufgabe an.
Finde Änderungen, die ausdrücklich inkompatibel, entfernt oder migrationspflichtig sind. Notiere betroffene Version, bisheriges Verhalten, Ersatz und angegebene Migration. Trenne veraltete Funktionen mit späterem Entfernungsdatum von Änderungen, die bestehende Integrationen bereits brechen.
- Was du bereitstellst
- Sichtbare Release-Dokumentation.
- Was du erhältst
- Breaking Changes und nötige Migrationsschritte.
Sieh dir Eingabe und Ergebnis an.
Beispielhafte Ein- und Ausgabe · ein Lehrbeispiel, kein tatsächlicher WebAct-Durchlauf
Beispiel Eingabe
Release notes say field full_name is replaced by display_name in version 2.
Vollständiges Beispiel
Breaking change: consumers using full_name must review the version-2 response and migrate to display_name as documented.
Lade diese Eingabe in den Prompt und kopiere ihn zum Ausprobieren nach WebAct. Dein Ergebnis kann vom Beispiel abweichen.
Entscheidungen und Fehlerbehebung.
Ist jede veraltete Funktion bereits ein Breaking Change?
Nein. Eine Deprecation kann der Entfernung vorausgehen. Bewahre Zeitplan und aktuellen Supportstatus der Release Notes.
Warum bleibt die Migrationsmaßnahme im Changelog unklar?
Die Notiz kann auf eine eigene Anleitung verweisen oder Umsetzungsdetails auslassen. Lass diese Lücke sichtbar, statt Ersatzverhalten zu erfinden.
Probiere es mit deiner eigenen Quelle.
Ersetze das Beispiel im Aufgaben-Prompt durch dein Material. Behalte nötige Anforderungen bei und kopiere die Aufgabe nach WebAct.
Aufgabe anpassen und kopieren ↑