MII IG Dokument
2027.0.0-ballot.2 - Germany Flagge

This page is part of the MII IG Dokument (v2027.0.0-ballot.2: 2027 Ballot 3) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Versionierung

Versionsschema

Das Modul Dokument folgt dem KDS-Schema der Kalender-Versionierung (CalVer) in einer SemVer-kompatiblen numerischen Form:

  • Format JJJJ.MINOR.PATCH[-label] — die aktuelle Version ist 2027.0.0-ballot.2;
  • JJJJ — das Jahr, in dem der Leitfaden gilt und genutzt werden soll; es tritt an die Stelle der Major-Version;
  • MINOR — wird für nicht brechende Ergänzungen und Präzisierungen erhöht;
  • PATCH — wird für Korrekturen und Fehlerbehebungen erhöht;
  • label — optionales Vorab- oder Build-Label, z. B. draft, ballot oder cibuild.

Versionen vergleichen

Stabile Releases lassen sich vergleichen, indem die numerischen Bestandteile als SemVer-artiges <major>.<minor>.<patch> gelesen werden, mit dem Kalenderjahr als Major-Komponente: 2026.1.0 ist neuer als 2026.0.3. Labels kennzeichnen den Vorab- oder Build-Status; zwischen Labels wird keine Reihenfolge abgeleitet.

Artefakt-Versionen

Alle veröffentlichten FHIR-Artefakte im Paket tragen dieselbe Version wie der Leitfaden und sein Paket. Ein Artefakt kann daher beim Release eine neue Version erhalten, obwohl es selbst unverändert geblieben ist. Die maschinenlesbaren Metadaten, die Versionsalgorithmus, Versionierungs-Politik, Paketquelle und Manifest-Parameter deklarieren, beschreibt die Seite Metadaten-Übersicht.

Release-Prozess

Releases folgen dem Module Release Workflow: Die Version wird im Release-Branch angehoben, der Changelog-Eintrag geschrieben, die Validierungs-Workflows laufen auf dem Release-Pull-Request, und nach dem Merge wird das Release getaggt. Die Änderungen jeder veröffentlichten Version verzeichnet die Änderungshistorie.

Versionsvergleich

Ab der zweiten formalen Publikation veröffentlicht dieser Leitfaden zusätzlich einen maschinell erzeugten Versionsvergleich. Er ergänzt die Änderungshistorie: Die Änderungshistorie erklärt warum und was zu tun ist, der Vergleich zeigt, was sich genau geändert hat.

Wo er liegt. Der Bericht ist Teil der veröffentlichten Website selbst: comparison-v<Vorversion>/index.html neben den Seiten des Leitfadens, verlinkt aus dem QA-Bericht. Der Index listet die verglichenen Artefakt-Paare; jedes Paar verlinkt eine Detailseite mit drei Ansichten — der Differenz-Analyse (was sich Element für Element geändert hat), der Vereinigung (alles, was eine der beiden Versionen erlaubt) und dem Schnitt (nur was beide Versionen erlauben).

Wie er erzeugt wird. Der Vorversions-Vergleicher des IG Publishers lädt das Paket des vorherigen Releases, ordnet jedes Profil, ValueSet und CodeSystem über die kanonische URL seinem Gegenstück zu, vergleicht die Paare und rendert den Bericht in die Build-Ausgabe — er wird also mit der Website veröffentlicht, ohne zusätzlichen Deployment-Schritt. Aktiviert wird er über den Parameter version-comparison — einen offiziellen IG-Publisher-Parameter aus der ig-parameters-Registry, durchgereicht über die sushi-config.yaml. Zwei Voraussetzungen müssen dafür erfüllt sein: eine Publikationshistorie an der kanonischen URL und ein ladbares Vorversions-Paket. Dieses Modul setzt den Parameter derzeit nicht — damit gilt der Publisher-Standard {last}; der Wert n/a ist der dokumentierte Weg, den Vergleich abzuschalten.

Abschalten. Die Repository-Variable ENABLE_VERSION_COMPARISON=false schaltet den Vergleich des Publishers in allen Build-Workflows dieses Moduls ab; solange der Parameter nicht gesetzt ist, bleibt sie ohne Wirkung.