Thema: compatibility
-
musl versus glibc unter Alpine: Warum manche vorkompilierten Binaries, Python-Wheels und das DNS-Verhalten abweichen
Das musl libc von Alpine ist nicht binärkompatibel zu glibc, hat einen anderen DNS-Resolver (parallele Abfragen, kein Rückfall auf die Suchdomäne), verwendet standardmässig die Locale C.UTF-8 statt einer vollständigen Locale-Datenbank und unterstützt kein Lazy Binding von Symbolen. Daraus erklärt sich, warum glibc-Binaries nicht starten, manylinux-Python-Wheels abgelehnt werden und manche DNS-Altkonfigurationen anders reagieren. gcompat kann manche unveränderten glibc-Binaries ausführen, eignet sich aber nicht zum Bauen von Software, die selbst glibc-Header benötigt.
-
Protocol Buffers: Feldnummern, unbekannte Felder und die Regeln für die Weiterentwicklung einer Nachricht
In Protocol Buffers identifiziert die Feldnummer, nicht der Name, ein Feld auf der Leitung, weshalb Nummern nie geändert oder wiederverwendet werden dürfen; das Hinzufügen von Feldern ist unbedenklich, das Entfernen nur dann sicher, wenn die Nummer nie wiederverwendet wird (eine reserved-Anweisung erzwingt das), alte Leser behalten unbekannte Felder, und die Erweiterung von int32 zu int64 ist nur bedingt sicher. ProtoJSON hat eigene, davon abweichende Regeln.
-
Das Vergleichen des OpenAPI-Dokuments in der CI erkennt Breaking Changes, die im Code-Review übersehen werden
Hypothese: Ein CI-Schritt, der das OpenAPI-Dokument jeder Änderung mit einem Breaking-Change-Klassifikator wie oasdiff gegen das veröffentlichte Dokument vergleicht, markiert entfernte Felder, verengte Typen und neue Pflichtparameter, die beim menschlichen Review des Code-Diffs übersehen werden, sodass weniger unbeabsichtigte Breaking Changes in ein Release gelangen.
-
Eine Funktion in einer Bibliothek als veraltet markieren: warnen, den Ersatz dokumentieren, planmässig entfernen
Eine Deprecation in einer Bibliothek besteht aus vier Teilen: einem Ersatz, der zuerst existiert, einer Laufzeitwarnung zusammen mit einem Dokumentationshinweis, der Version und Ersatz nennt, einem Eintrag im Changelog und einer Entfernungs-Version, die im Voraus durch eine Richtlinie festgelegt wird. PEP 387 verlangt bei Pythons jährlichem Rhythmus eine Deprecation-Frist von mindestens zwei Jahren und beschreibt eine rein dokumentarische «Soft Deprecation»; Django entfernt Übergangslösungen (Shims) frühestens zwei Feature-Releases nach der Warnung.
-
Schema-Evolution mit Avro und Parquet: Reader- und Writer-Schemas, zusammengeführte Dateien und Kompatibilitätsmodi
Avro gleicht das Schema eines Writers Feld für Feld mit dem Schema eines Readers ab, füllt fehlende Felder aus den Standardwerten des Readers und ignoriert unbekannte Felder; Parquet-Dateien mit unterschiedlichen, aber kompatiblen Schemas kann die lesende Engine mit einem gewissen Aufwand zusammenführen; eine Schema-Registry erzwingt Rückwärts-, Vorwärts- oder vollständige Kompatibilität. Optionale Felder mit Standardwerten hinzuzufügen ist der sichere Weg, Umbenennungen und Typänderungen sind es nicht.
-
Einen API-Endpunkt mit den Headern Deprecation und Sunset abkündigen
Das End of Life im Band ankündigen: Der Header Deprecation (RFC 9745) markiert eine Ressource als veraltet, der Header Sunset (RFC 8594) gibt an, wann sie nicht mehr funktionieren wird, und ein Link zur Dokumentation erklärt den Ersatz; dazu passend werden die verbleibenden Aufrufer protokolliert.
-
Protocol-Buffers-Enums: unbekannte numerische Werte entsprechend dem Laufzeitverhalten behandeln
Eine vorwärtskompatible Enum-Behandlung anhand des gewählten Schema-Modus und der jeweiligen Sprachimplementierung planen.
-
Mehrere Release-Linien pflegen: welche Fixes wohin gehören
Eine Support-Richtlinie ist eine Tabelle der Release-Linien mit je einem Status (Feature, Bugfix, nur Sicherheit, End of Life) und einer Regel, welche Fix-Klassen auf welche Linien zurückportiert werden. Python pflegt eine Reihe mit Bugfix-Releases für zwei Jahre und reinen Sicherheits-Releases für drei weitere; Django portiert kritische Fixes auf das letzte Feature-Release zurück und Sicherheits- sowie Datenverlust-Fixes auf die letzten zwei plus die Long-Term-Support-Linien; Rust unterstützt nur die jeweils neueste Stable-Version. Ein kleines Projekt sollte die Tabelle veröffentlichen und standardmässig das engste Versprechen abgeben, das es halten kann.
-
Behauptungen der Version zuordnen, die sie abdeckt
Den Versionsumfang explizit darstellen und sich weigern, eine Behauptung aus der aktuellen Dokumentation auf eine unbekannte oder inkompatible Installation anzuwenden.
Maschinenlesbar: JSON