Breaking Changes MÜSSEN berichtet und erläutert werden

Ein Versionsabschnitt mit einer Breaking Change ist erst vollständig, wenn er ausdrücklich und in diesem Changelog beantwortet:

• Was genau sich geändert hat zwischen den beiden Versionen — das Artefakt, das Element, die alte und die neue Einschränkung (nicht nur „Profil X wurde überarbeitet“).
• Was das für bestehende Daten bedeutet: Validieren Daten, die der Vorversion entsprachen, weiterhin gegen die neue Version? Falls nein: welche Ressourcen und Elemente sind betroffen, und wie zeigt sich der Fehler?
• Was Implementierende tun sollten: die Empfehlung der Autorinnen und Autoren zur Migration bestehender Daten auf die neue Version — Transformationsschritte, Standardwerte, Umkodierungs-Hinweise — oder die ausdrückliche Aussage, dass kein Migrationspfad bereitgestellt wird, und warum.

Was als Breaking Change zählt — behandeln Sie eine Änderung als Breaking Change, wenn sie eines der Folgenden tut, auch wenn sie klein wirkt: eine Kardinalität verschärft (0..* → 1..1), eine Binding-Stärke erhöht (example → required), Codes aus einem required-ValueSet entfernt, ein Element oder einen Slice entfernt oder umbenennt, einen Typ einengt, eine Invariante oder eine Must-Support-Pflicht hinzufügt oder eine kanonische URL ändert. Im Zweifel: als Breaking Change berichten.

Breaking für wen: benennen Sie beide Perspektiven — gespeicherte Daten (Instanzen, die gegen die alte Version valide sind) und Implementierungen (Clients und Server, die dagegen gebaut wurden; ein entfernter Suchparameter bricht Implementierungen, während jede gespeicherte Instanz valide bleibt).

Die Versionsnummer warnt niemanden. Das KDS-Kalender-Versionsschema (JJJJ.n.n) trägt kein Major-Signal wie SemVer — dieser Changelog-Abschnitt ist die einzige Warnung, die Lesende bekommen.

Verlinken Sie das technische Delta. Ab der zweiten formalen Publikation aktivieren Sie den Versionsvergleich des IG Publishers (version-comparison in sushi-config.yaml — siehe die Seite Versionierung zur Einrichtung und ihren Voraussetzungen); er veröffentlicht einen maschinell erzeugten Vergleich unter comparison-v<Vorversion>/index.html. Verlinken Sie ihn aus dem Versionsabschnitt, damit die Erläuterung und der technische Diff nebeneinanderstehen.

Kennzeichnen Sie solche Einträge deutlich (zum Beispiel mit dem Präfix BREAKING:), damit sie beim Überfliegen des Abschnitts nicht übersehen werden können.