Direkte Antwort
Jeder veröffentlichte Menschentext, jedes Datenschema und Dateipaket trägt eine Version. Klassifizieren Sie getrennt eine unwesentliche Änderung wie Rechtschreibkorrektur, ein rückwärtskompatibles neues Feld oder eine Erklärung sowie eine inkompatible Änderung, die bestehendes Feld, Norm oder Verbraucherverhalten bricht. Überschreiben Sie eine ältere Version nicht still mit einer inkompatiblen Änderung. Veröffentlichen Sie ein neues Schema mit Änderungsprotokoll, Liste betroffener Datensätze, Alt-zu-Neu-Migrationszuordnung, Kompatibilitätstest, Abkündigungsdatum und Archivbeziehung.
Einfach erklärt
Denken Sie an einen Stadtplan. Einen Schreibfehler im Straßennamen zu korrigieren ist nicht dasselbe wie eine Brücke zu schließen und eine neue Straße zu eröffnen. Wer die neue Route nutzt, braucht Datum, Alternative und den Zeitpunkt, bis zu dem der alte Plan verwendbar bleibt.
Warum ist das wichtig?
Ein Feld still zu löschen oder eine Norm zu verändern kann alte Anwendungen Daten falsch lesen lassen und zwischen Sprachen unterschiedliche Aussagen erzeugen. Eine Versionsnummer genügt nicht; Wirkung und Migrationsweg müssen bekannt sein.
Nicht verwechseln
- Eine Rechtschreibkorrektur ist eine redaktionelle Änderung ohne wesentliche Bedeutungsänderung.
- Eine rückwärtskompatible Ergänzung bietet ein neues Feld oder eine Option, ohne ältere Verbraucher zu brechen.
- Eine inkompatible Schemaänderung kann ältere Verbraucher falsch oder unvollständig arbeiten lassen.
- Eine normative Änderung verändert Gebot oder Verbot; sie ist nicht nur eine technische Schemaänderung.
- Abkündigung ist ein Lebenszyklus mit angekündigtem Ende und Migrationsweg, keine sofortige Feldlöschung.
Was ist zu tun?
- Definieren Sie öffentliche Felder, normative Datensätze und Dateiverträge versioniert.
- Klassifizieren Sie jede Änderung als redaktionell, rückwärtskompatibel, inkompatibel, normativ oder sicherheitsbezogen.
- Nennen Sie im Änderungsprotokoll geändertes Feld, Grund, betroffene Datensätze, Datum und Entscheidungsverantwortlichen.
- Verbinden Sie Menschen-, JSON-, Schema-, API-, PDF- und Sprachversionen mit derselben Freigabeerklärung.
- Stellen Sie bei inkompatibler Änderung Alt-zu-Neu-Feldzuordnung, Transformationsbeispiel und Migrationswerkzeug oder -anleitung bereit.
- Kündigen Sie Warnung, Unterstützungszeitraum, Entfernungsdatum und sicheren Rückfallweg an.
- Testen Sie Rückwärtskompatibilität mit alten Beispielen, Schema und Parität mit neuen Beispielen und archivieren Sie die Freigabe unveränderlich.
Wie wird geprüft?
- Sind Änderungsklasse und wesentliche Wirkung ausdrücklich benannt?
- Bezeichnet die Versionsnummer auf jeder Oberfläche dieselbe Freigabe?
- Wurde eine inkompatible Änderung als kleine Korrektur verborgen?
- Sind Änderungsprotokoll, betroffene Datensätze und Migrationsweg vollständig?
- Wurde Kompatibilität mit älteren Verbrauchern und Dateien tatsächlich getestet?
- Hat ein abgekündigtes Feld Datum, Warnung und Alternative?
- Ist die alte Version unveränderlich verfügbar und mit der neuen verbunden?
Grenze
Nummernschemata wie MAJOR.MINOR.PATCH signalisieren Änderungen nützlich, beweisen aber keine Kompatibilität. Dieselbe Änderung kann Buch, Norm, Datensatz und API verschieden betreffen. Sicherheits- oder Rechtsnotwendigkeit kann eine Migrationsfrist verkürzen; Grund und Wirkung sind dennoch zu erfassen.
Merksatz
Eine neue Freigabe ist nicht nur eine neue Zahl, sondern ein erklärtes Änderungsversprechen.
Quellen dieses Eintrags
- S07W3C, *JSON-LD 1.1*Standard
- S14DataCite, *Versioning*Identitätsinfrastruktur
- S15DataCite, *Connecting Versions with Related Identifiers*Identitätsinfrastruktur
- S35W3C, *PROV-O: The PROV Ontology*Standard
- S53JSON Schema, *Specification — Draft 2020-12*Offene technische Spezifikation
- S54*Semantic Versioning 2.0.0*Offene Spezifikation zur Versionierung
- S58Zenodo, *About Records*Offizielle Repository-Dokumentation