Sujet : compatibility
-
musl et glibc sur Alpine : pourquoi certains binaires précompilés, certaines wheels Python et la résolution DNS se comportent différemment
La libc musl d'Alpine n'est pas compatible binaire avec glibc, utilise un résolveur DNS différent (requêtes parallèles, sans repli sur les domaines de recherche), prend C.UTF-8 comme locale par défaut au lieu d'une base de locales complète et ne gère pas la liaison paresseuse des symboles. Ces écarts expliquent les binaires glibc qui ne s'exécutent pas, les wheels manylinux rejetées et certaines configurations DNS héritées qui se comportent autrement ; gcompat permet d'exécuter certains binaires glibc non modifiés, mais pas de compiler un logiciel qui exige les en-têtes de glibc.
-
Protocol Buffers : numéros de champ, champs inconnus et règles d'évolution d'un message
Dans Protocol Buffers, c'est le numéro du champ, et non son nom, qui identifie le champ sur le fil ; ces numéros ne doivent donc jamais changer ni être réutilisés. Ajouter des champs est sans risque pour la compatibilité binaire, en supprimer ne l'est que si le numéro n'est jamais réutilisé (une déclaration reserved l'impose), les anciens lecteurs conservent les champs inconnus, et l'élargissement d'int32 vers int64 n'est sûr que sous conditions. ProtoJSON obéit à ses propres règles, différentes.
-
Comparer le document OpenAPI en intégration continue détecte des changements cassants que la revue de code manque
Hypothèse : une étape d'intégration continue qui compare le document OpenAPI de chaque changement à celui déjà publié, à l'aide d'un classifieur de changements cassants tel qu'oasdiff, signale des champs supprimés, des types restreints et de nouveaux paramètres obligatoires que la revue humaine du diff de code laisse passer, de sorte que moins de changements cassants non intentionnels atteignent une publication.
-
Déprécier une fonction dans une bibliothèque : avertir, documenter le remplacement, supprimer selon un calendrier
Une dépréciation dans une bibliothèque comporte quatre volets : un remplacement qui existe d'abord, un avertissement à l'exécution complété d'une note de documentation nommant la version et le remplacement, une entrée dans le journal des modifications, et une version de suppression fixée à l'avance par une politique. La PEP 387 exige une période de dépréciation d'au moins deux ans sous la cadence annuelle de Python, et décrit une dépréciation douce, purement documentaire ; Django ne retire les rustines de compatibilité (shims) au plus tôt que deux versions fonctionnelles après l'avertissement.
-
Évolution de schéma avec Avro et Parquet : schémas lecteur et écrivain, fusion de fichiers et modes de compatibilité
Avro résout le schéma de l'écrivain — qui accompagne les données — face au schéma du lecteur, champ par champ, en complétant les champs manquants avec les valeurs par défaut du lecteur et en ignorant les champs inconnus ; des fichiers Parquet aux schémas différents mais compatibles peuvent être fusionnés par le moteur de lecture, à un certain coût ; un registre de schémas impose une compatibilité ascendante, descendante ou totale. Ajouter des champs optionnels avec valeur par défaut est le geste sûr ; renommer des champs ou changer leur type ne l'est pas.
-
Déprécier un point de terminaison d'API avec les en-têtes Deprecation et Sunset
Annoncer la fin de vie directement dans les échanges : l'en-tête Deprecation (RFC 9745) marque une ressource comme dépréciée, l'en-tête Sunset (RFC 8594) indique la date à laquelle elle cessera de fonctionner, et un Link vers la documentation explique le remplacement ; associer cela à une journalisation des appelants restants.
-
Énumérations Protocol Buffers : traiter les valeurs numériques inconnues selon le comportement du runtime
Prévoir une gestion des énumérations compatible en amont, en fonction du mode de schéma choisi et de l'implémentation du langage.
-
Prendre en charge plusieurs lignes de version : quels correctifs vont où
Une politique de support est un tableau des lignes de version, chacune avec un statut (fonctionnalités, correctifs, sécurité uniquement, fin de vie) et une règle indiquant quelles classes de correctifs sont rétroportées vers quelles lignes. Python maintient une série avec des versions correctives pendant deux ans, puis des versions sécurité uniquement pendant trois ans de plus ; Django rétroporte les correctifs critiques vers la dernière version de fonctionnalités, et les correctifs de sécurité et de perte de données vers les deux dernières plus les lignes à support à long terme ; Rust ne prend en charge que la dernière version stable. Un petit projet a intérêt à publier le tableau et à se limiter par défaut à la promesse la plus étroite qu'il peut tenir.
-
Faire correspondre les affirmations à la version qu'elles couvrent
Représenter explicitement la portée en version, et refuser d'appliquer une affirmation tirée de la documentation courante à une installation inconnue ou incompatible.
Lisible par machine : JSON