Tema: compatibility
-
musl frente a glibc en Alpine: por qué difieren algunos binarios preconstruidos, las ruedas (wheels) de Python y el comportamiento DNS
La biblioteca musl de Alpine no es compatible binariamente con glibc, tiene un solucionador DNS distinto (paralelo, sin recurrir a la búsqueda por dominio), usa por defecto la configuración regional C.UTF-8 en lugar de una base de datos de configuraciones regionales completa, y no admite el enlace perezoso de símbolos: diferencias que explican por qué fallan al ejecutarse los binarios enlazados con glibc, por qué se rechazan las ruedas manylinux de Python y por qué algunas configuraciones DNS heredadas se comportan de forma distinta. gcompat puede ejecutar algunos binarios de glibc sin modificar, pero no puede usarse para compilar software que a su vez requiera las cabeceras de glibc.
-
Protocol Buffers: números de campo, campos desconocidos y las reglas para evolucionar un mensaje
En Protocol Buffers, lo que identifica un campo en la codificación de red es el número de campo, no el nombre, así que los números no deben cambiarse ni reutilizarse nunca; añadir campos es seguro para la codificación de red, eliminarlos solo es seguro si el número no se reutiliza jamás (algo que impone una declaración reserved), los lectores antiguos conservan los campos desconocidos, y ampliar int32 a int64 solo es seguro de forma condicional. ProtoJSON tiene sus propias reglas, distintas.
-
Comparar (diff) el documento OpenAPI en la integración continua detecta cambios incompatibles que la revisión de código pasa por alto
Hipótesis: un paso de integración continua que compara el documento OpenAPI de cada cambio con el publicado, mediante un clasificador de cambios incompatibles como oasdiff, señala campos eliminados, tipos restringidos y nuevos parámetros obligatorios que la revisión humana del diff de código pasa por alto, de modo que llegan menos cambios incompatibles no intencionados a una versión publicada.
-
Deprecar una función en una biblioteca: avisar, documentar el reemplazo, retirar según calendario
Una deprecación de biblioteca tiene cuatro partes: un reemplazo que existe primero, un aviso en tiempo de ejecución más una nota de documentación que indica la versión y el reemplazo, una entrada en el registro de cambios, y una versión de eliminación fijada de antemano por política. PEP 387 exige un período de deprecación de al menos dos años bajo el ciclo anual de Python y describe una deprecación suave solo en la documentación; Django no elimina los adaptadores antes de dos versiones de funcionalidad posteriores al aviso.
-
Evolución de esquemas con Avro y Parquet: esquemas de lector y de escritor, archivos combinados y modos de compatibilidad
Avro resuelve el esquema del escritor frente al esquema del lector campo por campo, rellenando los campos faltantes con los valores predeterminados del lector e ignorando los desconocidos; los archivos Parquet con esquemas distintos pero compatibles pueden combinarse mediante el motor de lectura, a cierto costo; un registro de esquemas impone compatibilidad hacia atrás, hacia adelante o completa. Añadir campos opcionales con valores predeterminados es la jugada segura; renombrar campos y cambiar tipos no lo es.
-
Cómo dar de baja un endpoint de API con las cabeceras Deprecation y Sunset
Anuncia el fin de vida del endpoint dentro de la propia respuesta: la cabecera Deprecation (RFC 9745) marca el recurso como obsoleto, Sunset (RFC 8594) indica cuándo dejará de funcionar y un Link a la documentación explica la alternativa; complétalo registrando qué clientes siguen llamando.
-
Enums de Protocol Buffers: gestionar los valores numéricos desconocidos según el comportamiento del runtime
Cómo planificar un tratamiento de enums compatible con versiones futuras, según el modo de esquema elegido y la implementación de cada lenguaje.
-
Mantener varias líneas de versiones: qué correcciones van a cada una
Una política de soporte es una tabla de líneas de versiones, cada una con un estado (desarrollo de funcionalidades, corrección de errores, solo seguridad, fin de vida), y una regla que indica qué clases de correcciones se portan a cada línea. Python mantiene una serie con versiones de corrección de errores durante dos años y versiones solo de seguridad durante tres más; Django porta las correcciones críticas a la última versión de funcionalidades y las de seguridad y pérdida de datos a las dos últimas más las líneas de soporte a largo plazo; Rust solo da soporte a la última versión estable. Un proyecto pequeño debería publicar la tabla y adoptar por defecto la promesa más acotada que pueda cumplir.
-
Vincular cada afirmación a la versión a la que se refiere
Indicar de forma explícita el alcance de versión de cada afirmación y negarse a aplicar lo que dice la documentación actual a una instalación cuya versión se desconoce o no es compatible.
Legible por máquina: JSON