Resumen

  • La admisión de un parche en una rama estable es una evaluación del cambio; prolongar el mantenimiento de una versión antigua es una decisión aparte sobre capacidad.
  • Kernel.org vincula esa duración con las necesidades aguas abajo y el tiempo de los mantenedores. Por eso una fecha de fin prevista no equivale a una promesa de soporte comercial.

Un kernel antiguo puede seguir siendo útil para un dispositivo mucho después de su lanzamiento. Eso no significa que cualquier arreglo propuesto vaya a incorporarse a su rama estable, ni que la rama reciba mantenimiento mientras siga vendiéndose el producto. Linux tiene dos filtros distintos en este punto. Confundirlos convierte una etiqueta útil en una garantía que nadie ha ofrecido.

El primer filtro se aplica a cada parche. Las reglas del kernel estable exigen que el arreglo, o uno equivalente, ya exista en la rama principal. Debe ser claramente correcto y estar probado, ocupar como máximo 100 líneas contando el contexto, respetar las reglas de envío de parches y resolver un problema real de usuario o añadir un identificador de dispositivo. Entre los ejemplos figuran bloqueos, caídas, corrupción de datos, fallos de seguridad reales, peculiaridades de hardware y errores de compilación. Las reglas descartan riesgos teóricos sin explicar cómo podrían explotarse y cambios que no aporten nada al usuario. Estos límites facilitan la revisión y reducen el riesgo de introducir otro fallo en una rama que ya está en uso. Las reglas de la rama estable detallan tanto los criterios como las vías de envío.

Superar ese filtro no evita la revisión. El procedimiento documentado coloca las propuestas aceptadas en una cola, pide revisión a otros desarrolladores y al responsable del subsistema afectado, y prueba el resultado en versiones candidatas. Una objeción puede sacar un parche de la cola. Que el cambio haya llegado antes a la rama principal acredita su procedencia; no promete que todas las series antiguas lo reciban automáticamente. También debe aplicarse con sentido a la versión de destino y superar la revisión correspondiente.

El segundo filtro determina cuánto dura la rama. Kernel.org describe las versiones de soporte prolongado como árboles antiguos que reciben correcciones importantes, por lo general con menos frecuencia que las ramas estables activas. Su guía señala varios factores para elegirlas: novedades importantes, necesidades de distribuciones comerciales, demanda de fabricantes de dispositivos, carga de trabajo y disponibilidad de los mantenedores. Una nueva serie de soporte prolongado parte de una fecha de fin estimada que puede ampliarse si el interés de la industria ayuda a sostener más años de trabajo. La propia guía dice que esa proyección no es fija. La copia consultada para este artículo muestra la fecha del 25 de febrero de 2026; su explicación de la política sirve, pero la tabla de versiones no representa la situación de octubre de 2026. La página de versiones de Kernel.org explica esos factores y las fechas previstas.

El papel de Greg Kroah-Hartman importa aquí sin convertirlo en todo el sistema. La Linux Foundation lo identifica como Fellow, responsable de la rama estable de Linux y de varios subsistemas. El documento sobre el proceso de desarrollo nombra a Greg y Sasha Levin como equipo estable y también describe la participación de responsables de subsistema y revisores. En una entrevista de 2018, Greg recordó que fue uno de los desarrolladores voluntarios cuando comenzaron las versiones estables en 2005. Añadió que llegó a mantener simultáneamente más árboles y relacionó ese trabajo con proteger los dispositivos que ya estaban en circulación. Es un relato retrospectivo suyo, no un recuento actual de ramas ni una prueba de que él decida a solas qué serie recibe soporte prolongado. El perfil de la Linux Foundation, el proceso de desarrollo del kernel y la entrevista a Greg acotan el alcance de su función.

Para un operador, esa diferencia cambia lo que puede inferir de una etiqueta de soporte. Una rama de soporte prolongado de kernel.org es una línea de mantenimiento comunitaria. Una distribución puede entregar un kernel basado en ella, añadir sus propios cambios o mantener otro árbol según su calendario. Kernel.org remite a los usuarios de kernels de distribución al canal de soporte de su proveedor y advierte que los desarrolladores del kernel pueden no dar soporte a esas versiones. Hay que identificar quién mantiene el kernel exacto de la imagen desplegada, qué proceso cubre sus correcciones de seguridad y regresiones, y si el compromiso del proveedor alcanza la vida útil del producto. La etiqueta LTS por sí sola no responde ninguna de esas preguntas contractuales. La FAQ de Kernel.org y su página de versiones distinguen esos ámbitos.

El mecanismo económico es sencillo, aunque el número de versión lo oculte. Cada serie que continúa requiere trabajo: alguien debe evaluar los arreglos, revisar los retroportados, probar las versiones y responder si aparece una regresión. Las fuentes públicas no cuantifican esas horas ni su coste. Sí indican que las necesidades aguas abajo y la disponibilidad de los mantenedores influyen en qué líneas reciben más años de atención. La demanda industrial puede justificar el esfuerzo; no sustituye a quienes tienen que realizarlo.

La Nota 64 de Heng Lu ofrece una prueba analítica útil: un documento de coordinación puede describir un estado futuro sin hacerlo realidad por sí solo. Este artículo no presenta Linux como un sistema diseñado según esa nota. Usada solo como lente, la distinción ayuda a explicar por qué las palabras «soporte prolongado» y una fecha estimada no son garantías que se ejecuten por sí mismas. Describen un arreglo que debe seguir adoptándose y manteniéndose. La Nota 64 es una referencia analítica, no una fuente sobre la política del kernel.

Análisis

Los dos filtros distribuyen el riesgo en niveles distintos. Las reglas de parches limitan lo que puede incorporarse a una rama existente; la selección de versiones prolongadas limita cuántas ramas antiguas puede seguir sosteniendo la comunidad. Un filtro más estricto no crea años de disponibilidad de personal, y una demanda industrial fuerte no vuelve seguro un retroportado sin revisar. El compromiso práctico existe solo si tanto el arreglo como la capacidad para mantener su rama siguen siendo viables.

Ese horizonte depende de una coalición que puede cambiar. Un fabricante puede necesitar una versión antigua para equipos ya desplegados; una distribución puede necesitar una base estable para un lanzamiento; los mantenedores deben disponer de tiempo para revisar y probar el trabajo. Las fuentes públicas no explican cómo se reparten esas aportaciones ni cuánto peso tiene cada participante. Sí muestran que el soporte prolongado responde a la demanda y al trabajo disponible, no solo a la antigüedad del número de versión.

Fuentes