Roteiro

lançamentos e desenvolvimento para QGIS seguir um cronograma de tempo base.

  • Os números pares da versão (2.18, 3.2 etc) são versões de lançamento.
  • Os números ímpares da versão (2.99, 3.1 etc) são versões de desenvolvimento.

O lançamento irá acontece de quatro em quatro meses. Os primeiros três meses são dedicados ao novo desenvolvimento. No último mês anterior ao lançamento, de paralisar feição é convocado no mês final é usado para testar, correção de erros, tradução e preparações para o lançamento. Quando é feito o lançamento, um ramo com o número par de lançamento é criado e o ramo master avança para a próxima versão ímpar. Após o lançamento é feito a chamada para o empacotando.

Sempre a cada terceiro lançamento (iniciando na versão 2.8), teremos uma versão de longo tempo de lançamento (LTR) que será mantida até a próxima edição LTR.

Nota

Durante o desenvolvimento do QGIS 3.0 e 3.2, uma exceção a esse cronograma foi implementada. Visto o roteiro abaixo para informações ajustadas

Fase de desenvolvimento

Na fase de desenvolvimento, os programadores trabalham em novas funcionalidades para o próximo lançamento. Os usuários podem usar compilações nightly para a maioria das plataformas para ver o progresso de desenvolvimento, faça um teste preliminar e fornece um relatório de erros e os pensamentos para ajudar no desenvolvimento.

Congelamento de atualizações

Na fase de congelamento de atualizações, novas funcionalidades não são mais permitidas e o foco dos programadores se torna a estabilização da versão do QGIS. Isto também torna as versões “nightly builds” em pré-lançamentos.

Usuários devem iniciar testes intensivos destes pré-lançamentos para verificar o aparecimento de erros que devam ser corrigidos na versão a ser lançada. Todos erros devem ser reportados (veja Bugs, Features and Issues). Tudo que não for notado continuará na próxima versão. Apenas em casos de problemas muito sérios serão feitos ajustes antes de uma nova versão. Dessa forma, testes dos pré-lançamentos e reporte de erros são muito importantes.

In the feature freeze developers monitor the bugtracker and start working on fixing the reported issues and update the visual changelog with the features they added.

Com o início da paragem de novas funcionalidades os ficheiros de tradução são actualizados para que os tradutores possam começar o seu trabalho. Note que poderá ser um trabalho incremental, apesar da paragem das novas funcionalidades, a correcção dos erros podem introduzir alterações nas cadeias de texto da tradução.

Two weeks before the release a hard freeze is initiated, after which only fixes to severe problems and regressions introduced after the feature freeze are allowed in.

O gerente de lançamento anuncia isso em paralisar feição.

Lançamento

On major and minor release dates the release branch is created and the release is tagged and tar balls are prepared. Point releases are just tagged and tar balls are created.

Os empacotadores são notificados de que a embalagem pode começar.

Uma vez que alguns pacotes estejam disponíveis, o lançamento pode ser anunciado e o site é atualizado de acordo.

Calendário de lançamento

O cronograma está alinhado para produzir aproximadamente as mesmas datas todos os anos tendo em visto os nossos lançamentos a cada quatro meses e a versão LTR no final de fevereiro.

Iniciados após 2,12 a fase de desenvolvimento é sempre 12 semanas e a fase de congelamento é de pelo menos 5 semanas. Remanescentes são usados para estender a fase de congelamento da liberação da LTR.

Point releases will happen every month on the latest release branch and the LTR branch, if there are backports.

Nos primeiros quatro meses após o lançamento, um novo LTR é também o atual LR. Nesta fase, o novo LTR não substitui o anterior LTR nos repositórios LTR. Isso acontece assim que um novo LR é lançado.

The 2.18 release will replace the 2.14 release as LTR, but not replace 2.14 in the LTR package repositories before 3.0 is released.

Cronograma:

Evento Últimas Novidades Versão Longo Prazo Freeze Data 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 1
FF     3.7 2019-04-26 17 3
PR 3.6.3 3.4.8 . 2019-05-17 20 3
HF       2019-06-07 23 2
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 4
PR/FF 3.8.3 3.4.12 3.9 2019-09-13 37 6
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

Legenda do evento:

Evento Descrição
LTR Lançamento a longo prazo, começo da nova fase de desenvolvimento
LR Lançamento regular, começar de novo fase de desenvolvimento
FF Congelamento de recursos, o fim da fase de desenvolvimento
HF hard freeze
SF Soft freeze with bi-monthly vote
PR Lançamento pontual da versão mais recente e ramo LTR
EPR Lançamento de ponto extra

Localização de pré-lançamentos /nightly builds

Plataforma Localização
Windows Lançamento candidato semanal (instalador standalone)
OSGeo4W
Linux Debian/Ubuntu
MacOS Mac OS