Ubuntu publica dos tipos de versiones con ciclos de vida radicalmente distintos. Una versión LTS (Long Term Support) sale cada dos años, siempre en abril de años pares — 20.04, 22.04, 24.04 — y recibe soporte de seguridad y correcciones durante cinco años desde Canonical de forma gratuita, ampliables a diez con Ubuntu Pro (antes Ubuntu Advantage). Una versión intermedia (interim release) sale cada seis meses, en abril y octubre, y su soporte se acaba a los nueve meses, punto en el que debes actualizar o quedarte sin parches. No hay término medio: o actualizas, o asumes el riesgo.
El motivo de este diseño es pragmático. Las LTS congelan versiones de paquetes relativamente maduras, corren ciclos de prueba más largos y son el objetivo principal de los equipos de QA de Canonical y de los ISV que certifican software sobre Ubuntu. Las versiones intermedias sirven para meter en producción kernels más nuevos, versiones de GNOME más recientes, compiladores actualizados — cosas que un escritorio de desarrollo agradece, pero que en un servidor de producción son ruido. Fíjate en que el modelo no es “LTS = estable, intermedia = inestable”: ambas son igual de estables en el sentido de no romperse; lo que cambia es el horizonte de soporte y la antigüedad de los paquetes base.
¿Cuándo usas cada una? En un servidor, base de contenedor, CI runner de larga vida o cualquier máquina que no quieras tocar cada nueve meses, LTS es la respuesta correcta. Ubuntu 22.04 LTS “Jammy Jellyfish” sigue siendo la versión más desplegada a día de hoy en infraestructura empresarial; 24.04 LTS “Noble Numbat” es la LTS actual desde abril de 2024 y el objetivo razonable para instalaciones nuevas. Las versiones intermedias — 23.10, 24.10, 25.04 — tienen su lugar en un portátil de desarrollo donde quieres Python 3.13 o un kernel 6.x reciente sin compilar nada a mano.
El riesgo real de equivocarse es quedarte sin actualizaciones de seguridad sin darte cuenta. Una versión intermedia caducada no te avisa dramáticamente; simplemente deja de recibir parches. En un servidor con puertos expuestos, eso es un problema serio antes de que pase un mes.
# Comprobar qué versión tienes y cuánto soporte le queda lsb_release -a # Muestra: Release, Codename (jammy/noble/etc.), Description completa # Ver la fecha de fin de soporte de forma explícita ubuntu-support-status # En versiones intermedias caducadas verás paquetes marcados como # "unsupported" — señal de que hay que actualizar # Herramienta oficial para actualizar entre versiones # En LTS: salta directamente a la siguiente LTS (22.04 -> 24.04) # En intermedia: salta a la siguiente release (24.10 -> 25.04) sudo do-release-upgrade # Si estás en una LTS y quieres saltar a una intermedia (no recomendado # en producción), tienes que forzarlo explícitamente: sudo do-release-upgrade -d # El flag -d (development/proposed) activa rutas de upgrade no estándar; # en producción no lo toques # Revisar qué paquetes instalados ya no tienen soporte en la versión actual ubuntu-support-status --show-unsupported # Versión de kernel instalada — relevante porque LTS y versiones intermedias # usan ramas distintas; en 24.04 LTS viene el 6.8, en 24.10 el 6.11 uname -r # Ver los repositorios activos: en LTS verás "jammy" o "noble", # en una intermedia verás "oracular" (24.10) o similar cat /etc/apt/sources.list # En sistemas modernos con deb822 format: ls /etc/apt/sources.list.d/
El comando ubuntu-support-status merece atención especial: no solo te dice si tu versión está soportada, sino que inspecciona cada paquete instalado y clasifica los que vienen de PPAs externos o que Canonical ya no mantiene. En una auditoría rápida de servidor, es más útil que mirar la fecha de la release a secas.
El path de upgrade que hace do-release-upgrade sin flags — LTS a LTS directamente — es deliberado. Si estás en 22.04, el comando espera a que 24.04.1 esté disponible (el primer point release, que sale unos meses después del .0) antes de ofrecerte el salto, precisamente para evitar que subas a una LTS recién publicada con bugs conocidos. Puedes forzarlo antes con do-release-upgrade -d, pero en un servidor en producción ese flag debería hacerte entrar en modo “¿realmente sé lo que estoy haciendo?”.
La diferencia de paquetes entre LTS e intermedias no es trivial. En Ubuntu 22.04 LTS el Python de sistema es 3.10; en 24.04 LTS es 3.12; una versión intermedia como 24.10 ya lleva 3.12 también pero con paquetes de entorno más nuevos. Si tu aplicación depende de una versión concreta de Python, Node, o Go, revisar la tabla de paquetes antes de elegir la base de tu contenedor o VM te ahorra semanas de parches en backports o compilaciones manuales. La página packages.ubuntu.com permite buscar por codename exactamente para esto.
[Ubuntu] Todo lo descrito en este artículo es específico de Ubuntu. Debian, que es la base upstream de Ubuntu, tiene su propio modelo de releases completamente distinto (stable/testing/unstable, sin el concepto de LTS ni de versiones intermedias con fecha fija).