El ciclo de release: de la merge window a tu distro
El latido del kernel: la merge window de dos semanas donde entra todo lo nuevo, la serie de candidatas -rc donde solo se corrige, el release estable que Linus etiqueta un domingo, los kernels stable y los LTS de soporte largo, y el largo viaje de un cambio desde mainline hasta el kernel que corre tu distribución o tu teléfono.
El kernel no se publica cuando está terminado —nunca lo está— sino con la regularidad de un metrónomo: una release nueva cada nueve o diez semanas, año tras año, década tras década. Esa cadencia no es un detalle administrativo: es la disciplina de ingeniería que permite que decenas de miles de cambios entren de forma predecible sin hundir el proyecto en el infierno de integración que estuvo a punto de matarlo en los años del desarrollo 2.x. Sigamos un cambio desde que se abre la puerta hasta que corre en tu máquina.
- Entender la merge window de dos semanas y la serie de candidatas
-rc. - Distinguir mainline, los kernels stable y los LTS de soporte largo.
- Saber por qué existe el salto de la serie 6.x a la 7.0 y qué significa.
- Trazar el viaje completo de un cambio desde
mainlinehasta una distribución.
La merge window y las candidatas -rc
El ciclo empieza con la merge window: dos semanas en las que Linus abre las puertas y va integrando las pull requests que los mantenedores prepararon durante el ciclo anterior en sus ramas -next. Solo entra material que ya pasó por linux-next; la merge window no es momento de escribir código nuevo, sino de recogerlo. Al cerrarse, Linus etiqueta la primera candidata, -rc1, y las puertas se cierran de golpe.
La escala de esas dos semanas es difícil de exagerar: una merge window típica absorbe más de diez mil commits llegados en cientos de pull requests, todo el trabajo que decenas de subsistemas maduraron durante el ciclo anterior. Por eso importa tanto que ya estuviera en linux-next: no hay tiempo material para revisarlo entonces, solo para integrarlo.
A partir de ahí empieza la estabilización. Cada domingo Linus publica una candidata nueva —-rc2, -rc3, hasta típicamente -rc7 u -rc8— y en todas ellas la regla es una sola: solo correcciones. Nada de funciones nuevas. Cada semana llegan menos parches y de menor riesgo, el árbol se aquieta, y cuando Linus juzga que ya no quedan sorpresas, etiqueta la versión final. Ese es mainline: la fuente de verdad, la única rama de la que todo lo demás desciende.
7.0-rc1 <- cierre de la merge window: todo lo nuevo ya esta dentro
7.0-rc2 \
7.0-rc3 | solo correcciones, una por semana, los domingos
... |
7.0-rc7 /
7.0 <- release estable: Linus la etiqueta y se abre la siguiente windowEl número de versión del kernel no tiene semántica: un 7.0 no promete nada distinto de un 6.20. Linus incrementa el número mayor cuando el menor se vuelve incómodamente grande, y el umbral es puramente estético —lo hizo tras 2.6.39, tras 3.19, tras 4.20 y tras 5.19. El salto de la serie 6.x a Linux 7.0, en torno a 2025-2026, es exactamente eso: no rompe nada, no cambia el proceso, solo aligera la aritmética. Que no te confunda con el versionado semántico de una biblioteca.
Stable y LTS: la vida después de mainline
Mainline avanza rápido y no mira atrás, pero casi nadie corre mainline en producción. En cuanto Linus etiqueta 7.0, Greg Kroah-Hartman y Sasha Levin abren la serie stable: 7.0.1, 7.0.2, 7.0.3… que solo reciben correcciones ya presentes en mainline —de nuevo, upstream first— marcadas por su autor con la etiqueta Cc: stable@vger.kernel.org, más una selección automática de parches candidatos que el proceso AUTOSEL propone. El stable nunca inventa: solo retropropaga arreglos que ya demostraron su valor arriba.
Una release al año se corona como LTS (Long Term Support), y esa recibe correcciones durante mucho más tiempo. Aquí hay una tensión viva en 2026: históricamente los LTS se mantenían seis años, pero en 2023 Greg Kroah-Hartman anunció que los nuevos apuntarían a unos dos años salvo demanda real, porque casi nadie probaba los años finales y el coste de mantenerlos recaía sobre unos pocos hombros. No es un detalle técnico: es el primer síntoma del problema que verás en la lección 4, la sostenibilidad de quienes sostienen el kernel.
El viaje hasta tu distro
Ninguna distribución seria entrega mainline crudo. Entre el árbol de Linus y tu máquina hay un último tramo, y se recorre de dos maneras muy distintas.
El modelo rolling
Arch, Fedora y las distros de vanguardia siguen de cerca la última serie stable. Recibes hardware y funciones nuevas pronto, a cambio de moverte casi al ritmo de mainline.
El modelo empresarial
RHEL, SLES o Debian congelan una versión base y le retropropagan correcciones durante años. Un kernel “5.14” de una empresa puede contener miles de parches de versiones muy posteriores: un franken-kernel estable por fuera y modernísimo por dentro.
El modelo Android
Android parte de un LTS, lo envuelve en el Generic Kernel Image y le añade los módulos del fabricante del chip. Miles de millones de teléfonos corren, así, un descendiente directo de un -rc que Linus etiquetó un domingo.
El resultado es que una misma línea de código escrita hoy puede tardar semanas en llegar a un usuario de Arch y años en llegar a un servidor RHEL, viajando por mainline, luego por stable, luego por el LTS, y por fin por la maquinaria de retropropagación de una distribución. Cada salto la revalida.
flowchart LR MW[Merge window: 2 semanas] --> RC[Serie rc: solo correcciones] RC --> ML[Release estable: mainline] ML --> ST[Serie stable X.Y.Z] ST --> LTS[Un LTS anual: soporte largo] LTS --> ROLL[Distro rolling: Arch, Fedora] LTS --> ENT[Distro empresarial: RHEL, SLES] LTS --> AND[Android: Generic Kernel Image]
Levanta la vista de las etiquetas de versión y mira el mecanismo, porque encierra una de las lecciones más profundas de la ingeniería a gran escala. Durante los años del desarrollo 2.x, el kernel vivía escindido: una rama “de desarrollo” con números impares donde todo hervía y se rompía, y una rama “estable” con números pares que quedaba congelada durante años mientras la otra divergía sin control. Fusionar una en otra era una agonía periódica —el infierno de integración— y el proyecto casi se ahoga en ella. La solución no fue una herramienta ni un algoritmo: fue un ritmo. Al fijar una release cada nueve o diez semanas por reloj, y no por lista de funciones, el kernel convirtió la integración de un acontecimiento traumático y raro en un latido constante y aburrido. La merge window abre, entra lo que estaba maduro, las candidatas lo pulen, sale la versión, y a otra cosa. Nadie tiene que esperar dos años para que su trabajo llegue a la gente; a lo sumo espera al próximo latido. Y esa misma cadencia es la que hace posible la asombrosa horquilla de la última lección: que un mismo cambio sirva a la vez al usuario de vanguardia que lo tiene en semanas y al servidor empresarial que lo recibirá dentro de una década, porque stable y LTS son diques que van dejando pasar solo lo ya probado, a distintas velocidades, desde el mismo río. Cuando entiendes que la predecibilidad —no la genialidad puntual— es lo que permite a decenas de miles de personas construir juntas sin pisarse, comprendes por qué el proceso del kernel se estudia como se estudian las grandes instituciones: es una máquina de convertir caos en cadencia.
- Busca el anuncio de la última release de Linus en la lista
linux-kernely cuenta cuántas candidatas-rcnecesitó: razona qué habría significado una-rc9o-rc10. - Explica por qué un parche solo puede entrar en la serie stable si ya está en mainline, y qué agujero cerraría esa regla si no existiera.
- Consulta las fechas de fin de soporte de los LTS actuales y discute qué implica para una empresa elegir hoy su kernel base.
- Toma un commit concreto de mainline y describe, salto a salto, el camino que recorrería hasta aparecer en un teléfono Android.
- Argumenta por qué el número
7.0no promete más estabilidad ni más rupturas que el6.20que lo habría precedido.