Zo herken je breaking changes in release notes.
Leg bij een breaking change oud gedrag, nieuw gedrag en opgegeven migratiestap vast. Behandel niet elke release-opmerking als een breuk.
Stem de werkwijze af op je taak.
Zoek wijzigingen die expliciet incompatibel, verwijderd of migratieplichtig zijn. Noteer getroffen versie, eerder gedrag, vervanging en gegeven migratiestap. Houd deprecations met toekomstige verwijderdatum apart van wijzigingen die bestaande integraties nu al breken.
- Wat je aanlevert
- Zichtbare releasedocumentatie.
- Wat je krijgt
- Incompatibele wijzigingen en vereiste migratiestappen.
Bekijk de invoer en het resultaat.
Illustratieve invoer en uitvoer · een leervoorbeeld, geen live uitvoering van WebAct
Voorbeeld invoerveld
Release notes say field full_name is replaced by display_name in version 2.
Uitgewerkt voorbeeld
Breaking change: consumers using full_name must review the version-2 response and migrate to display_name as documented.
Laad deze invoer in de prompt en kopieer deze naar WebAct om de taak te proberen. Je resultaat kan afwijken van het voorbeeld.
Keuzes en probleemoplossing.
Is elke deprecated functie nu al een breaking change?
Nee. Deprecation kan aan verwijdering voorafgaan. Behoud de tijdlijn en huidige ondersteuning uit de release notes.
Waarom is de migratiestap in de changelog onduidelijk?
De release-opmerking kan naar een aparte gids verwijzen of implementatiedetails weglaten. Houd het gat zichtbaar in plaats van vervangend gedrag te verzinnen.
Probeer het met je eigen bron.
Vervang het voorbeeld door je eigen materiaal in de taakprompt. Behoud de eisen die je nodig hebt en kopieer de taak naar WebAct.
De taak aanpassen en kopiëren ↑