Mantener varias líneas de versiones: qué correcciones van a cada una

Qué es

Una política de versiones soportadas responde a la pregunta «¿recibirá la versión A.B esta corrección?» antes de que alguien la haga. Tiene dos partes: una tabla de líneas de versiones con su estado y sus fechas, y reglas de backport por clase de corrección. El proceso de publicación de Django es un ejemplo compacto: la rama principal (main) recibe las nuevas funcionalidades; la última versión de funcionalidades recibe correcciones de los problemas que bloquean una publicación (seguridad, pérdida de datos, fallos que provocan caídas, errores graves en funcionalidades nuevas, regresiones); las correcciones de seguridad y de pérdida de datos se aplican en main, en las dos últimas ramas de funcionalidades y en cualquier rama de soporte a largo plazo (LTS) vigente; las correcciones de documentación se portan con más libertad. PEP 602 describe la serie de Python como mantenida durante cinco años: versiones de corrección de errores durante los dos primeros y, después, versiones de código fuente solo de seguridad durante tres más (a partir de Python 3.13). El libro de Rust plantea el extremo opuesto: solo se da soporte a la versión estable más reciente, de modo que cada versión recibe soporte durante seis semanas.

Por qué importa

Los usuarios no pueden actualizar según el calendario del proyecto, y quien mantiene el código no puede corregir todas las líneas para siempre. Sin una regla escrita, cada solicitud de backport se convierte en una negociación, y las correcciones de seguridad acaban aplicándose solo en main sin que nadie lo diga, mientras los usuarios de la línea anterior creen estar cubiertos.

Cómo aplicarlo

• Publica la tabla donde los usuarios la buscan: línea, estado, primera versión y fin de vida previsto. Mantén una rama por cada línea soportada, con nombres coherentes (Django usa stable/A.B.x).
• Valor por defecto para un proyecto pequeño: la última versión de funcionalidades recibe todas las correcciones; la anterior recibe correcciones de seguridad durante un período declarado; nada más. Amplía el alcance solo cuando haya un segundo mantenedor.
• Haz el backport con cherry-pick, incluyendo en el mensaje la referencia al commit original, y publica una versión con él; una corrección en una rama sin versión publicada no sirve a nadie.
• Limita la matriz de CI a las líneas soportadas; una línea sin soporte que sigue probándose invita a que se pidan correcciones para ella.
• Anuncia el fin de vida con antelación en el registro de cambios (changelog) y retira la línea de la tabla en la fecha prevista.
• Ofrece soporte a largo plazo solo si de verdad puedes prometer esos años; una etiqueta LTS abandonada es peor que no tener ninguna.

Trampas

Portar funcionalidades con el pretexto de que son correcciones, lo que convierte una línea estable en una segunda línea de desarrollo. Corregir un problema de seguridad solo en main. Dejar que la matriz de CI crezca con cada versión soportada de cada dependencia hasta que nada esté en verde. Olvidar que la documentación de las líneas antiguas también debe seguir siendo accesible.