Tema: release-management
-
Etiquetas y releases: etiquetas ligeras frente a etiquetas anotadas y cómo se propagan
Una etiqueta ligera es solo un nombre para un commit; una etiqueta anotada es un objeto con quien la crea, la fecha, un mensaje y, opcionalmente, una firma, razón por la cual git describe ignora las etiquetas ligeras de forma predeterminada y por la que los releases deberían usar etiquetas anotadas o firmadas; las etiquetas no se envían junto con las ramas a menos que se use --follow-tags o --tags, y una etiqueta ya publicada nunca debería moverse.
-
Cherry-picking: cuándo encaja y qué le cuesta al historial
git cherry-pick reproduce el cambio de un commit como un nuevo commit con un ID distinto; es la herramienta adecuada para retroportar una corrección a una rama de mantenimiento o rescatar un commit de una rama abandonada, pero cada pick crea un duplicado que los merges no pueden reconocer, así que hay que registrar el origen con -x y fusionar en lugar de aplicar picks cuando se quiere la rama entera.
-
Cadencia de publicación para un proyecto pequeño: trenes basados en tiempo frente a publicar cuando esté listo
Un número de versión indica qué promete una publicación; una política de cadencia indica cuándo ocurren las publicaciones. Rust publica una versión estable cada seis semanas a partir de un tren nightly, beta, stable; Python pasó a una publicación anual de funcionalidades con la PEP 602, y Django emite publicaciones de funcionalidades según un calendario basado en tiempo, con publicaciones de parches según se necesiten. Un proyecto pequeño puede copiar esa forma: publicaciones de funcionalidades según un calendario o cuando se acumula algo notable, publicaciones de parches cada vez que se aplica una corrección.
-
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.
-
Conventional Commits: tipos de commit legibles por máquinas
La especificación Conventional Commits añade a los mensajes de commit un prefijo tipado (feat, fix y otros) y marcas de cambios incompatibles, de modo que los changelogs y los incrementos de versión puedan derivarse automáticamente.
-
Versionado semántico: qué promete un número de versión
El Versionado Semántico 2.0.0 codifica promesas de compatibilidad en MAJOR.MINOR.PATCH y define los sufijos de prelanzamiento y de metadatos de compilación; solo funciona si se declara la API pública.
-
Versionado de APIs: cuándo y cómo romper la compatibilidad
La mayoría de los cambios pueden ser aditivos; una nueva versión mayor es el último recurso, porque duplica la superficie que hay que mantener. Versiona en la ruta o en el tipo de medio, documenta las reglas de compatibilidad y marca como obsoleto antes de eliminar.
-
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.
-
Cómo mantener un changelog pensado para personas
Un changelog es una lista curada y ordenada cronológicamente de los cambios relevantes de cada versión; Keep a Changelog define una estructura sencilla (Added, Changed, Deprecated, Removed, Fixed, Security) y una sección Unreleased.
Legible por máquina: JSON