QGIS 3.0 - Como, quando e o quê; isso implica

Muitos estão nos perguntando:

Quando QGIS 3.0 será lançado?

No ano passado (2015), a equipe do projeto começou a investigar quando e como QGIS 3.0 deveria ser lançado. Eles prometem, de acordo com uma postagem de Anita Graser, que eles iriam transmitir claramente aos usuários e desenvolvedores seus planos antes de lançar o QGIS 3.0. Recentemente, eles tentaram expor algumas das considerações para um lançamento do QGIS 3.0 e, no final do post, há uma oportunidade para apresentarmos nossas idéias.

Por que 3.0?

Normalmente, uma versão principal é reservada para os momentos em que uma grande mudança é feita na API do seu software. Esta pausa não é uma decisão trivial para o projeto QGIS, pois somos centenas de milhares de usuários que dependem do QGIS, tanto para nosso próprio uso quanto para serviços prestados a terceiros.

Ocasionalmente, a separação da API é necessária para acomodar a atualização da arquitetura com abordagens aprimoradas, novas bibliotecas e correções às decisões tomadas no passado.

Quais são as conseqüências de quebrar a API?

Uma das razões pelas quais esta quebra da API no QGIS 3.0 é que ele terá um grande impacto, que poderia quebrar as centenas de plugins desenvolvidos que não seriam mais compatíveis com a nova API e os autores destes teriam que fazer uma revisão de seus desenvolvimentos para garantir a compatibilidade com a nova API.

A extensão das mudanças necessárias depende em grande parte:

• Muitas mudanças na API afeta a funcionalidade atual.
  Como muitos pontos plugins autores usaram partes da API que iria mudar.

• Quais são as principais mudanças para 3.0?

Há quatro áreas-chave que estão à procura de mudança em 3.0:

Qt4 a atualização QT5: Este é o conjunto básico de bibliotecas que o QGIS é construído no nível superior, falamos do nível funcional CORE da plataforma. O QT também fornece bibliotecas para realizar gerenciamento de memória, operações de conectividade e gerenciamento de gráficos. O Qt4 (no qual o QGIS está baseado atualmente) não está sendo desenvolvido pelos mantenedores da biblioteca Qt e pode ter problemas de funcionalidade com algumas plataformas (por exemplo, OS X) e até mesmo facilitar o gerenciamento de versões binárias (por exemplo, Debian Testing e a próxima versão do Debian "Esticar"). O processo de trazer o QGIS para o QT5 já tem um avanço importante (principalmente o que Matthias Kuhn fez) que junto com Marco Bernasocchi fumam no Android "QField" baseado inteiramente no QT5. No entanto, existem algumas limitações em colocar o novo QT5 em funcionamento devido ao seu impacto no QGIS – em particular com widgets de navegador da web (usados ​​principalmente no Composer e também em alguns outros lugares no QGIS).

PyQt4 a atualização PyQt5: Estas são as mudanças relativas ao idioma Python para Qt no qual a API QGIS Python se baseia. É proposto alterar a biblioteca do QT5 C ++, também é esperado que mova a biblioteca Python para PyQt5 para que os benefícios da nova API QT5 no Python possam ser explorados.
Atualizando Python Python 2.7 3 para: Atualmente tudo roda em Python 2.7. Python 3 é a versão mais recente de python e é recomendado pelos líderes desse projeto. Python 2 é ligeiramente incompatível com Python 3 (quase proporcional à incompatibilidade entre QGIS 2 e Qgis 3). Muitos desenvolvedores tornaram o Python Python 3 amplamente compatível com Python 2, mas a compatibilidade com versões anteriores não é tão boa.
Melhorar QGIS própria API: Um dos problemas em manter a compatibilidade da API entre as versões é que você precisa conviver com suas escolhas de design a longo prazo. Todo esforço é feito no QGIS para não quebrar a API em uma série de versões menores. O lançamento de uma versão do QGIS para 3.0 com uma API não suportada atualmente nos dará a oportunidade de "limpar a casa" corrigindo coisas na API com as quais não estamos em conformidade. Você pode ver uma lista provisória de 3.0 as alterações propostas para a API.

Como suporta a alteração da API 3.0

Como já mencionado, a versão 3.0 será interrompida com o QGIS versão 2.xe há uma chance de que muitos plug-ins, aplicativos existentes e outros códigos baseados na API atual sejam interrompidos. Então, o que pode ser feito para mitigar as mudanças? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias e outros desenvolvedores de ponta têm procurado maneiras de mitigar o número de alterações de quebra de API enquanto continuam a avançar a base de código QGIS sendo baseada na próxima geração de bibliotecas e sua própria API interna. Durante nossa última reunião do Comitê Diretor do Projeto QGIS, nós geofumimos várias possibilidades. A tabela a seguir resume o que Matthias Kuhn graciosamente resumiu e que parcialmente tentamos transliterar neste artigo de acordo com o Eles publicou em seu blog:

Há duas coisas importantes a nota sobre o Matthias proposta:

Na primeira faseO trabalho é feito na série para completar 2.x apoio QT5, PyQt5 usando Python 3.0, apoiando Qt4, PyQt4 e Python 2.7. Isto implica que todas as alterações feitas na primeira fase seria compatível com versões anteriores 2.x. serão introduzidas funcionalidades Python serão incorporados de forma que a antiga API PyQt4 ainda pode ser usado especialmente quando compilado contra QT5, PyQt5, Python 3.0. Usando QGIS compilados contra Qt4, PyQt4 e Python 2.7 não iria quebrar a compatibilidade.
Na segunda faseEle iria trabalhar para produzir QGIS 3.0, introduzindo a nova API, remover completamente o Python 2.7, incluindo suporte para Qt4 e PyQt4. Os novos recursos do python que entram na primeira fase será mantido, tendo em conta todo o código python e desenvolvimentos para versões 2.x de QGIS continuar a trabalhar sobre as versões 3.x de QGIS. Esta fase também é esperado para introduzir mudanças na API QGIS que podem quebrar alguns plugins. Para abordar esta irá fornecer a migração orientação aa para tentar facilitar a migração de versões 2.x QGIS 3.x qgis versões.

Caveat.emptor

Existem alguns truques para ser feitas para garantir que a migração para o QGIS 3.0 soar menos dolorosa.

• 1. SDeve-se observar que, embora a abordagem declarada acima tente minimizar a quantidade de trabalho que existe na criação de scripts em python nos plug-ins, isso não será necessariamente 100%. Provavelmente haverá casos em que o código terá que ser ajustado e, pelo menos em todos os casos, ele provavelmente terá que ser revisado para garantir que continue a funcionar corretamente.
  2. Não existe um recurso financeiro formalmente estabelecido para pagar aos desenvolvedores que voluntariamente investem seu tempo neste processo de migração. Por causa disso, será muito difícil fornecer prazos exatos de quanto tempo cada parte do processo levará. Essa incerteza deve ser levada em consideração no planejamento. Claro, doações são bem-vindas para ajudar a fazer isso acontecer.
  3. Pode haver desenvolvedores e instituições por aí que estão financiando novos recursos para a série QGIS 2.x e isso pode afetar seu trabalho. É necessário incluir nos planos e orçamentos destes projetos, uma determinada dotação para fazer face à migração para a plataforma QGIS 3.x.
  4. Se a equipe do QGIS trabalhar em uma "mudança total", haverá um tempo relativamente curto durante o qual o QGIS estará instável e mudando constantemente devido às atualizações contínuas do QGIS 3.0.
  4. Se você desenvolver de uma maneira 'evolucionária', você corre o risco de que o desenvolvimento 3.0 possa demorar mais, a menos que você tenha um grupo leal de desenvolvedores trabalhando nele e preparando-o para a portabilidade.

  Propostas

À luz de todas as informações acima, um dos dois cursos de ação são propostas:

proposta 1:

Lance uma versão provisória 2.16 e comece a trabalhar na versão 3.0 como prioridade, com uma janela de desenvolvimento de 8 meses. As alterações feitas na versão 2.16 buscarão ser compatíveis com a versão 3.0 (ver python3 / pytq5).

proposta 2:

Cumplicidade uma vez 3.0 com uma janela de duração mais prolongada em QT5, Python 3.0 e PyQt5 e pedir os desenvolvedores a fazer o seu trabalho em 3.0. Continue com versões 2.x com a frequência habitual até 3.0 está pronto.

propostas alternativas

Tem uma proposta alternativa? QGIS está interessado em saber sobre as alternativas possíveis. Se você deseja enviar uma proposta, envie para Tim@qgis.org com o assunto “Proposta QGIS 3.0”.

Deve seguir o QGIS blogueDe onde veio esta publicação.