Desde la versión 1.0, el número de versión de Django funciona como sigue:
Las versiones se numeran en la forma A.B o A.B.C.
A.B es el número de versión de lanzamiento de características. Cada versión será compatible con retroceso en su mayoría con la versión anterior. Las excepciones a esta regla se enumerarán en las notas de liberación.
C es el número de versión de parche, que se incrementa para los lanzamientos de corrección de errores y seguridad. Estos lanzamientos serán 100% compatibles con retroceso con la versión anterior del parche. La única excepción es cuando un problema de seguridad o pérdida de datos no puede ser resuelto sin romper la compatibilidad con retroceso. Si esto sucede, las notas de liberación proporcionarán instrucciones detalladas para actualizar.
Antes de una nueva versión de lanzamiento de características, haremos lanzamientos alpha, beta y candidatos a la liberación. Estos son de la forma A.B alpha/beta/rc N, lo que significa el Nth alpha/beta/candidato a la liberación de la versión A.B.
Los textos traducidos son:
Para obtener más información sobre cómo el proyecto Django emite nuevas liberaciones con fines de seguridad, por favor consulte nuestras políticas de seguridad.
Las liberaciones de características (A.B, A.B+1, etc.) sucederán aproximadamente cada ocho meses – para obtener detalles, consulte el proceso de liberación. Estas liberaciones contendrán nuevas características, mejoras a las características existentes y otras.
Las liberaciones de parches (A.B.C, A.B.C+1, etc.) se emitirán según sea necesario, para corregir errores y/o problemas de seguridad.
Estas liberaciones serán 100% compatibles con la liberación de características asociada, a menos que esto sea imposible por razones de seguridad o para prevenir pérdida de datos. Por lo tanto, la respuesta a «¿Debería actualizar a la última liberación de parches?» siempre será «sí».
Algunas liberaciones de características serán designadas como liberaciones con soporte a largo plazo (LTS). Estas liberaciones recibirán correcciones de seguridad y pérdida de datos aplicadas durante un período garantizado de tiempo, típicamente tres años.
Consulte la página de descarga para obtener las liberaciones que han sido designadas con soporte a largo plazo.
Con Django 2.0, los números de versión utilizarán una forma suelta de versionamiento semántico tal que cada versión posterior a una LTS aumentará al siguiente «cero punto» de versión. Por ejemplo: 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS), etc.
SemVer facilita ver a simple vista cómo son compatibles las versiones entre sí. También ayuda a anticipar cuándo se eliminarán los shim de compatibilidad. No es una forma pura de SemVer ya que cada versión de características continuará teniendo un par de incompatibilidades documentadas hacia atrás donde no sea posible o no valga la pena el costo de una ruta de deprecación. Además, las deprecaciones iniciadas en una versión LTS (X.2) se eliminarán en una versión no «cero punto» (Y.1) para acomodar nuestra política de mantener los shim de deprecación durante al menos dos versiones de características. Lee el siguiente apartado para un ejemplo.
Una versión de características puede deprecarse ciertas características de versiones anteriores. Si una característica está deprecada en la versión de características A.x, continuará funcionando en todas las versiones A.x (para todas las versiones de x) pero lanzará advertencias. Las características deprecadas se eliminarán en la versión B.0, o B.1 para las características deprecadas en la última versión de características A.x para asegurarse de que las deprecaciones se hagan durante al menos 2 versiones de características.
Por ejemplo, si decidimos empezar a deprecación de una función en Django 4.2:
Django 4.2 contendrá una réplica compatible hacia atrás de la función que lanzará un RemovedInDjango51Warning.
Django 5.0 (la versión que sigue a 4.2) continuará conteniendo la réplica compatible hacia atrás.
Django 5.1 eliminará la característica de manera directa.
Las advertencias están silenciosas por defecto. Puedes activar el display de estas advertencias con la opción python -Wd.
Un ejemplo más genérico:
X.0
X.1
X.2 LTS
Y.0: Se agregaron los shims de desprecación en X.0 y X.1.
Y.1: Se agregó el drop de los shims de desprecación en X.2.
Y.2 LTS: No se eliminan los shims de desprecación (mientras Y.0 ya no está soportado, las aplicaciones terceras necesitan mantener la compatibilidad hacia atrás hasta X.2 LTS para facilitar las actualizaciones de LTS a LTS).
Z.0: Se agregaron los shims de desprecación en Y.0 y Y.1.
Consulte también la guía despreciando-una-característica.
En cualquier momento en el tiempo, el equipo de desarrollo de Django apoyará un conjunto de versiones a diferentes niveles. Consulte la sección de las versiones soportadas de la página de descarga para conocer el estado actual del soporte para cada versión.
La rama de desarrollo actual main obtendrá nuevas características y correcciones de errores que requieren reestructuraciones no triviales.
Los parches aplicados a la rama principal también deben aplicarse a la última rama de lanzamiento de características, para ser liberada en el próximo parche de lanzamiento de esa serie de características, siempre y cuando fijen problemas críticos:
Problemas de seguridad.
Errores de pérdida de datos.
Errores que hacen que la aplicación se caiga.
Errores importantes en nuevas características de la última versión estable.
Regressiones introducidas en las versiones antiguas de Django en la serie de lanzamiento actual.
La regla general es que los parches se aplicarán a la última rama de lanzamiento de características para errores que habrían impedido un lanzamiento en el primer lugar (bloqueadores de lanzamientos).
Los parches de seguridad y errores de pérdida de datos se aplicarán a la rama principal actual, las dos últimas ramas de lanzamiento de características y cualquier otra rama de soporte largo plazo.
Los textos traducidos son:
Como ejemplo concreto, considere un momento en tiempo a mitad de camino entre la liberación de Django 5.1 y 5.2. En este punto en el tiempo:
Se agregarán características a la rama principal de desarrollo, para ser liberadas como Django 5.2.
Las correcciones críticas se aplicarán a la rama stable/5.1.x, y se liberarán como 5.1.1, 5.1.2, etc.
Las correcciones de seguridad y las correcciones de errores para problemas de pérdida de datos se aplicarán a main y a las ramas stable/5.1.x, stable/5.0.x, y stable/4.2.x (LTS). Estos desencadenarán la liberación de 5.1.1, 5.0.5, 4.2.8, etc.
Las correcciones de documentación se aplicarán a main, y, si es fácilmente posible volver a aplicarlas, a la rama estable más reciente, 5.1.x.
Django utiliza un calendario de liberaciones basado en el tiempo, con liberaciones de características cada ocho meses o así.
Después de cada liberación de característica, el administrador de la liberación publicará una cronología para la próxima liberación de característica. La cronología para una próxima liberación de característica se puede encontrar en la página wiki correspondiente de la ruta, por ejemplo https://code.djangoproject.com/wiki/Version6.0Roadmap.
Comienza el trabajo en la versión de características A.B después de la congelación de características de la versión anterior, es decir, cuando se crea el rama stable/A.B-1.x.
Puedes encontrar la rama actualmente en desarrollo en el proceso de liberación de Django <https://code.djangoproject.com/#Djangoreleaseprocess> en Trac.
Todas las características principales y menores, incluidas las deprecaciones y cambios disruptivos, deben ser fusionadas antes de la congelación de características. Cualquier característica no realizada en este punto se retrasará a la siguiente versión de características.
En este punto, la rama stable/A.B.x se creará a partir de main.
Después de la alfa, también se vuelven a importar en stable/A.B.x las correcciones de errores fusionadas en main. Los refactores se vuelven a importar a discreción del que realiza la fusión. Los que realizan la fusión serán cada vez más conservadores con los reintegros, para evitar introducir regresiones.
De manera paralela a esta fase, main puede seguir recibiendo nuevas características, para su liberación en el ciclo A.B+1.
Si aún hay un flujo constante de bloqueadores de lanzamiento que llegan en la fecha planificada del candidato a lanzamiento, se liberará una beta 2 para fomentar más pruebas y la fecha del candidato a lanzamiento se retrasará ~1 mes.
El candidato a lanzamiento marca el congelamiento de cadenas, y sucede al menos dos semanas antes del lanzamiento final. Los traductores pueden entonces enviar actualizaciones de traducciones para su inclusión en el lanzamiento final. Después de este punto, no se deben agregar nuevas cadenas translatablebles.
Después del candidato a lanzamiento, solo se vuelven a incluir bloqueadores de lanzamiento y correcciones de documentación.
Idealmente, el lanzamiento final saldrá dos semanas después del último candidato a lanzamiento.
Si aún se están encontrando errores importantes 2 semanas después del candidato a lanzamiento, habrá una decisión sobre cómo proceder (probablemente se emitiría otro candidato a lanzamiento y la fecha del lanzamiento final se retrasaría).
Después de un lanzamiento de características (por ejemplo, A.B), el lanzamiento anterior pasará a modo de corrección de errores.
La rama para el lanzamiento de características anterior (por ejemplo, stable/A.B-1.x) incluirá correcciones de errores. Los errores críticos fijados en main deben también estar fijos en la rama de corrección de errores; esto significa que los commits deben separar limpiamente las correcciones de errores de las adiciones de características. El desarrollador que cometa una corrección a main será responsable de aplicar también la corrección a la rama actual de corrección de errores.
may 31, 2026