Hoja de Ruta

Los lanzamientos y desarrollo de QGIS sigue un plan basado en tiempo.

  • Versiones con números pares (2.18, 3.2, etc) son versiones liberadas.
  • Versiones con números impares (2.99, 3.1, etc) son versiones de desarrollo.

El lanzamiento ocurrirá cada cuatro meses. En los primeros tres meses tienen lugar los nuevos desarrollos. Después se invoca un congelamiento de características y el último mes es usado para realización de pruebas, corrección de errores, traducción y preparaciones del lanzamiento. Cuando el lanzamiento ocurre, se crea una rama con un número de lanzamiento par y la rama maestra avanza hacia la siguiente versión impar. Después del lanzamiento se emite un llamado para empaquetamiento.

Cada tercer lanzamiento (empezando con el 2.8) es un lanzamiento con soporte a largo plazo (LTR) que será mantenido hasta que el próximo LTR ocurra.

Fase de desarrollo

Durante la fase de desarrollo, los desarrolladores trabajan añadiendo nuevas características. Los adoptantes tempranos pueden usar los nightly builds que tenemos para las principales plataformas y así ver el progreso en el desarrollo, hacer pruebas preliminares y proporcionar reportes de errores e ideas para ayudar con el desarrollo.

Congelamiento de característica

En la fase de congelamiento de caracterísitcas, no se permite la incorporación de nuevas características y todos el enfoque de todos se traslada de mejorar QGIS a volverlo estable. Esto también convierte los nightly builds efectivamente en pre-lanzamientos.

Usuarios deben comenzar pruebas extensas de las pre versiones en sus ambientes para verificar que no hay problemas, ellos no querrían verlos en el próximo lanzamiento. Todos los problemas deben ser reportados (vea: :ref:`Bugs, Features and Issues `). Todo lo que pase desapercibido, terminará en el próximo lanzamiento. Backports a la última versión solo ocurrirá en caso de serios problemas. Por lo tanto las pruebas de las pre versiones y el reporte de problemas es muy importante.

En el congelamiento de características desarrolladores monitorean el reporte de bugs y comienzan a trabajar en corregir los problemas reportados y actualizan el registro visual de cambios con las funciones que ellos agregaron.

Con el inicio del congelamiento de características los archivos de traducción serán actualizados de modo que los traductores puedan comenzar su trabajo. Note que esto podría ser un proceso incremental y aunque las características o funciones esten congeladas, la corrección de bugs podrían introducir cambios en las cadenas de traducción.

Dos semanas antes del lanzamiento, se inicia una congelación, después de lo cual solo se solucionan los problemas graves y las regresiones introducidas después de que se produce el congelamiento de características.

El lider del lanzamiento anuncia esto en el congelamiento de funciones.

Lanzamiento

En las fechas de lanzamiento de mayores y menores versiones se crea la rama del lanzamiento, se etiqueta el lanzamiento y se preparan los archivos tar. Los lanzamientos de punto solo se etiquetan y se crean los archivos tar.

Se notifica a los empaquetadores que pueden comenzar con el empaquetamiento.

Una vez que los paquetes están disponibles el lanzamiento puede ser anunciado y el sitio Web se actualiza como corresponde.

Cronograma de lanzamiento

El plan se ajusta para producir aproximadamente las mismas fechas cada año dados nuestros lanzamientos cada cuatro meses con versiones de largo plazo a finales de febrero.

Comenzando despues de 2.12 la fase de desarrollo es siempre 12 semanas y la fase de congelamiento es al menos 5 semanas. El resto se usa para extender la fase congelamiento de las versiones de largo plazo

Se harán puntos de lanzamiento cada mes en la rama del ultimo lanzamiento y la rama de largo plazo, si hay backports.

En los primeros cuatro meses después de su lanzamiento, la nueva LTR convive con la LR actual. En esta fase, el nuevo LTR no reemplaza el LTR anterior en los repositorios de LTR. Esto sucede tan pronto como se lanza un nuevo LR.

La versión 2.18 reemplazará la versión 2.14 como version de largo plazo, pero no reemplaza a 2.14 en el repositorio de paquetes antes que 3.0 sea liberada.

Cronograma:

Evento Ultima Repositorio de largo-plazo Congelamiento Fecha Semana # Semanas
LTR/PR 3.4.0 2.18.25   2018-10-26 43 4
EPR 3.4.1     2018-11-02 44 4
PR 3.4.2 2.18.26   2018-11-23 47 4
PR 3.4.3 2.18.27   2018-12-21 51 4
PR/FF 3.4.4 2.18.28 3.5 2019-01-18 3 5
LR/PR 3.6.0 3.4.5   2019-02-22 8 4
PR 3.6.1 3.4.6   2019-03-22 12 4
PR 3.6.2 3.4.7   2019-04-19 16 4
PR/FF 3.6.3 3.4.8 3.7 2019-05-17 20 5
LR/PR 3.8.0 3.4.9   2019-06-21 25 4
PR 3.8.1 3.4.10   2019-07-19 29 4
PR 3.8.2 3.4.11   2019-08-16 33 3
FF     3.9 2019-09-06 36 1
PR 3.8.3 3.4.12   2019-09-13 37 4
HF       2019-10-11 41 2
LTR/PR 3.10.0 3.4.13   2019-10-25 43 4
PR 3.10.1 3.4.14   2019-11-22 47 4
PR 3.10.2 3.4.15   2019-12-20 51 4
PR/FF 3.10.3 3.4.16 3.11 2020-01-17 3 5
LR/PR 3.12.0 3.10.4   2020-02-21 8 4
PR 3.12.1 3.10.5   2020-03-20 12 4
PR 3.12.2 3.10.6   2020-04-17 16 4
PR/FF 3.12.3 3.10.7 3.13 2020-05-15 20 5
LR/PR 3.14.0 3.10.8   2020-06-19 25 4
PR 3.14.1 3.10.9   2020-07-17 29 4
PR 3.14.2 3.10.10   2020-08-14 33 4
PR/FF 3.14.3 3.10.11 3.15 2020-09-11 37 6
LTR/PR 3.16.0 3.10.12   2020-10-23 43 4
PR 3.16.1 3.10.13   2020-11-20 47 4
PR 3.16.2 3.10.14   2020-12-18 51 4
PR/FF 3.16.3 3.10.15 3.17 2021-01-15 3 5
LR/PR 3.18.0 3.16.4   2021-02-19 8 4

Leyenda de evento:

Evento Descripción
LLD Lanzamiento de largo plazo, inicio de nueva fase de desarrollo
LR Lanzamiento regular, inicio de nueva fase de desarrollo
FF Congelamiento de característica, fin de la fase de desarrollo
HF hard freeze
SF Congelamiento suave con votación bi-mensual
PR Punto de lanzamiento de la última versión y rama LLP
EPR Punto extra de lanzamiento

Ubicación de prelanzamientos / construcciones nocturnas

Plataforma Ubicación
Windows Candidato a lanzamiento semanal (instalador separado)
OSGeo4W
Linux Debian/Ubuntu
MacOS Mac OS