Calendario e información de contacto del equipo para los lanzamientos de parches de Kubernetes.
Para obtener información general sobre el ciclo de lanzamientos de Kubernetes, consulta la descripción del proceso de lanzamiento.
Nuestra cadencia habitual para los lanzamientos de parches es mensual. Por lo general, es un poco más rápida (de 1 a 2 semanas) para los primeros lanzamientos de parches después de una versión menor 1.X. Las correcciones de errores críticos pueden provocar un lanzamiento más inmediato fuera de la cadencia normal. También procuramos no realizar lanzamientos durante los principales periodos de vacaciones.
Consulta la página de Release Managers para obtener los detalles completos de contacto del equipo de Patch Release.
Por favor, danos un día hábil para responder, ¡es posible que estemos en una zona horaria diferente!
Entre lanzamientos, el equipo revisa las solicitudes de cherry pick entrantes de forma semanal. El equipo se pondrá en contacto con los autores de las solicitudes a través de la PR de GitHub, los canales de SIG en Slack, mensajes directos en Slack y por correo electrónico si surgen preguntas sobre la PR.
Por favor, sigue el proceso de cherry pick.
Los cherry picks deben estar listos para fusionarse en GitHub con las etiquetas adecuadas (por ejemplo,
approved, lgtm, release-note) y haber superado las pruebas de CI antes de la
fecha límite de cherry pick. Esto suele ser dos días antes del lanzamiento
previsto, pero podría ser más. Es mejor tener la PR lista lo antes posible,
ya que necesitamos tiempo para obtener la señal de CI después de fusionar tus cherry picks antes del lanzamiento real.
Las PR de cherry pick que no cumplan con los criterios de fusión se pospondrán y se les hará seguimiento para el próximo lanzamiento de parches.
De acuerdo con el KEP de soporte anual, la comunidad de Kubernetes soportará las series activas de lanzamientos de parches por un periodo de aproximadamente catorce (14) meses.
Los primeros doce meses de este marco temporal se considerarán el periodo estándar.
Hacia el final del duodécimo mes, ocurrirá lo siguiente:
Durante el periodo de dos meses en modo de mantenimiento, los Release Managers pueden generar lanzamientos de mantenimiento adicionales para resolver:
Al final del periodo de dos meses en modo de mantenimiento, la serie de lanzamientos de parches se considerará EOL (fin de vida útil) y los cherry picks hacia la rama asociada se cerrarán poco tiempo después.
Ten en cuenta que se eligió el día 28 del mes como fecha objetivo para el modo de mantenimiento y EOL por simplicidad (todos los meses lo tienen).
Los cronogramas pueden variar según la gravedad de las correcciones de errores, pero para facilitar la planificación, nos fijaremos los siguientes puntos de lanzamiento mensuales. También pueden ocurrir lanzamientos críticos no planificados entre estos.
| Lanzamiento mensual de parche | Fecha límite para Cherry Pick | Fecha prevista |
|---|---|---|
| Enero de 2026 | ||
| Enero de 2026 | ||
| Enero de 2026 | ||
| Enero de 2027 |
El próximo lanzamiento de parche es 1.37.2.
Kubernetes 1.37 entra en modo de mantenimiento el ; la fecha de fin de vida útil para Kubernetes 1.37 es .
| Lanzamiento de parche | Fecha límite para Cherry Pick | Fecha prevista | Nota |
|---|---|---|---|
| 1.37.1 |
El próximo lanzamiento de parche es 1.36.6.
Kubernetes 1.36 entra en modo de mantenimiento el ; la fecha de fin de vida útil para Kubernetes 1.36 es .
| Lanzamiento de parche | Fecha límite para Cherry Pick | Fecha prevista | Nota |
|---|---|---|---|
| 1.36.5 | |||
| 1.36.4 | |||
| 1.36.3 | |||
| 1.36.2 | |||
| 1.36.1 |
El próximo lanzamiento de parche es 1.35.10.
Kubernetes 1.35 entra en modo de mantenimiento el ; la fecha de fin de vida útil para Kubernetes 1.35 es .
| Lanzamiento de parche | Fecha límite para Cherry Pick | Fecha prevista | Nota |
|---|---|---|---|
| 1.35.9 | |||
| 1.35.8 | |||
| 1.35.7 | |||
| 1.35.6 | |||
| 1.35.5 | |||
| 1.35.4 | |||
| 1.35.3 | |||
| 1.35.2 | Out of band patch release to pick up a new version of Go to address several Go CVEs. No other changes. | ||
| 1.35.1 | January 2026 patches consolidated with February |
ℹ️ Kubernetes 1.34 entró en modo de mantenimiento el .
La fecha de fin de vida útil para Kubernetes 1.34 es .
| Lanzamiento de parche | Fecha límite para Cherry Pick | Fecha prevista | Nota |
|---|---|---|---|
| 1.34.12 | |||
| 1.34.11 | |||
| 1.34.10 | |||
| 1.34.9 | |||
| 1.34.8 | |||
| 1.34.7 | |||
| 1.34.6 | |||
| 1.34.5 | Out of band patch release to pick up a new version of Go to address several Go CVEs. No other changes. | ||
| 1.34.4 | January 2026 patches consolidated with February | ||
| 1.34.3 | |||
| 1.34.2 | October 2025 patches consolidated with November | ||
| 1.34.1 |
Estos lanzamientos ya no cuentan con soporte.
| Versión menor | Lanzamiento final de parche | Fecha de fin de vida útil | Nota |
|---|---|---|---|
| 1.33 | 1.33.13 | ||
| 1.32 | 1.32.13 | ||
| 1.31 | 1.31.14 | ||
| 1.30 | 1.30.14 | ||
| 1.29 | 1.29.14 | ||
| 1.28 | 1.28.15 | ||
| 1.27 | 1.27.16 | ||
| 1.26 | 1.26.15 | 1.26.15 was released in March 2024 (after the EOL date) to pick up a new version of Go to address several Go CVEs | |
| 1.25 | 1.25.16 | 1.25.16 was released in November 2023 (after the EOL date) to fix CVE-2023-5528 | |
| 1.24 | 1.24.17 | 1.24.17 was released in August 2023 (after the EOL date) to fix CVE-2023-3676 and CVE-2023-3955 | |
| 1.23 | 1.23.17 | ||
| 1.22 | 1.22.17 | 1.22.17 was released in December 2022 (after the EOL date) to backport registry changes and fix two critical issues. | |
| 1.21 | 1.21.14 | ||
| 1.20 | 1.20.15 | ||
| 1.19 | 1.19.16 | ||
| 1.18 | 1.18.20 | Created to solve regression introduced in 1.18.19 | |
| 1.17 | 1.17.17 | ||
| 1.16 | 1.16.15 | ||
| 1.15 | 1.15.12 | ||
| 1.14 | 1.14.10 | ||
| 1.13 | 1.13.12 | ||
| 1.12 | 1.12.10 | ||
| 1.11 | 1.11.10 | ||
| 1.10 | 1.10.13 | ||
| 1.9 | 1.9.11 | ||
| 1.8 | 1.8.15 | ||
| 1.7 | 1.7.16 | ||
| 1.6 | 1.6.13 | ||
| 1.5 | 1.5.8 | ||
| 1.4 | 1.4.12 | ||
| 1.3 | 1.3.10 | ||
| 1.2 | 1.2.7 |