QGIS 3.0 - Como, cando e que; implica

Moitos nos preguntan:

Cando se lanzará QGIS 3.0?

O ano pasado (2015) o equipo do proxecto comezou a investigar cando e como se lanzaría o QGIS 3.0. Eles prometeron, segundo un post de Anita Graser, que ían transmitir claramente aos usuarios e desenvolvedores dos seus plans antes de lanzar QGIS 3.0. Recentemente intentaron expoñer algunhas das consideracións para unha versión de QGIS 3.0 e ao final do post hai unha oportunidade para que presentemos as nosas ideas.

Por que 3.0?

Normalmente, unha versión importante resérvase para os momentos nos que se fai un gran cambio na API do seu software. Esta pausa non é unha decisión trivial para o proxecto QGIS xa que somos centos de miles de usuarios que dependemos de QGIS, tanto para o noso propio uso como para os servizos prestados a terceiros.

Á hora de romper a API é necesario acomodar a actualización da arquitectura coa mellora de enfoques, novas bibliotecas e correccións ás decisións tomadas no pasado.

Cales son as consecuencias de romper a API?

Unha das razóns polas que esta ruptura da API en QGIS 3.0 é que terá un gran impacto, o que podería romper os centos de complementos desenvolvidos que non serían compatibles coa nova API e os autores deberían facer unha revisión dos seus desenvolvementos para garantir a compatibilidade coa nova API.

A extensión dos cambios necesarios depende en gran medida de:

• Cantos cambios na API afectan a funcionalidade actual.
  En cantos puntos os autores do complemento usaron partes da API que cambiarían.

• Cales serán os principais cambios para 3.0?

Hai catro áreas clave que estás buscando para cambiar en 3.0:

Actualización de Qt4 a QT5: Este é o conxunto básico de bibliotecas que QGIS está construído no nivel superior, falamos do nivel funcional CORE da plataforma. QT tamén ofrece bibliotecas para realizar a xestión de memoria, operacións de conectividade e xestión de gráficos. Qt4 (no que QGIS está baseado actualmente) non está sendo desenvolvido actualmente polos mantedores da biblioteca Qt e pode ter problemas de funcionalidade con algunhas plataformas (por exemplo, OS X) e incluso facilitar a xestión de versións binarias (por exemplo, Debian Testing e a próxima versión de Debian). "Estiramento"). O proceso de levar QGIS a QT5 xa ten un avance importante (principalmente o que fixo Matthias Kuhn) que xunto con Marco Bernasocchi fuman no Android "QField" baseado integramente en QT5. Non obstante, hai algunhas limitacións para poñer en funcionamento o novo QT5 debido ao seu impacto en QGIS, en particular cos widgets do navegador web (utilizados principalmente en Composer e tamén nalgúns outros lugares en QGIS).

Actualiza PyQt4 a PyQt5: Estas son as modificacións relativas á linguaxe Python para Qt en que se basea a API de Python de QGIS. Proponse cambiar a biblioteca de QT5 C ++, tamén se espera que mova a biblioteca Python a PyQt5 para que os beneficios da nova API QT5 en Python poidan ser explotados.
2.7: actualizando Python 3 a Python Actualmente todo funciona con Python 2.7. Python 3 é a última versión de python e é recomendada polos líderes dese proxecto. Python 2 é lixeiramente incompatible con Python 3 (case proporcional á incompatibilidade entre QGIS 2 e Qgis 3). Moitos desenvolvedores fixeron que Python Python 3 fose compatible con Python 2, pero a súa compatibilidade non é tan grande.
Mellora da propia QGIS API: Un dos problemas ao manter a compatibilidade da API entre versións é que tes que vivir coas túas opcións de deseño a longo prazo. En QGIS faise todos os esforzos para non romper a API nunha serie de versións menores. Ao lanzar unha versión de QGIS para a 3.0 cunha API que non se admite actualmente, daranos a oportunidade de "limpar a casa" arranxando cousas na API coas que non cumprimos. Podes ver unha lista provisional de Cambios propostos para a API 3.0.

Como soportar cambiar a API 3.0

Como xa se mencionou, a versión 3.0 romperá coa versión 2.x de QGIS e existe a posibilidade de que moitos complementos, aplicacións existentes e outros códigos baseados na API actual rompan. Entón, que se pode facer para mitigar os cambios? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias e outros principais desenvolvedores estiveron a buscar xeitos de mitigar o número de cambios de rotura de API mentres seguían avanzando na base de código QGIS baseándose na próxima xeración de bibliotecas e na súa propia API interna. Durante a nosa última reunión do Comité de Dirección do Proxecto QGIS, geofumamos varias posibilidades. A seguinte táboa resume o que Matthias Kuhn resumiu amablemente e que en parte intentamos transliterar neste artigo segundo o que publicado no teu blog:

Hai dúas cousas importantes para ter en conta sobre a proposta de Matias:

Na primeira faseO traballo está feito na serie para completar 2.x apoio QT5, PyQt5 usando Python 3.0, apoiando Qt4, PyQt4 e Python 2.7. Isto implica que todos os cambios feitos na primeira fase serían compatibles con versións anteriores de 2.x. Incorporará funcións de Python para introducir a antiga PyQt4 API aínda cando se compila QT5, PyQt5, Python 3.0. Ao usar QGIS compilado contra Qt4, PyQt4 e Python 2.7, non existiría compatibilidade de colapso.
Na segunda faseÍa traballar para producir QGIS 3.0, introducindo a nova API, eliminar o Python 2.7, incluíndo soporte para Qt4 e PyQt4. As novas características do Python que entran na primeira fase estará sometido, tendo en conta todo o código Python e desenvolvementos para versións 2.x de QGIS seguir traballando sobre as versións 3.x de QGIS. Nesta fase tamén se espera introducir cambios na QGIS API que poidan romper algúns complementos. Para abordar esta pode fornecer a migración orientación aa para intentar facilitar a migración de versións 2.x QGIS 3.x qgis versións.

Caveat.emptor

Hai un par de trucos que deben ser implementados para garantir que a migración a QGIS 3.0 soe menos dolorosa.

• 1. SCómpre ter en conta que, aínda que o enfoque exposto anteriormente trata de minimizar a cantidade de traballo en scripts python nos complementos, este non será necesariamente do 100%. Probablemente haberá casos nos que o código se teña que modificar e, polo menos, en todos os casos é probable que teña que revisarse para asegurarse de que siga funcionando correctamente.
  2. Non hai ningún recurso financeiro establecido formalmente para pagar aos desenvolvedores que invisten voluntariamente o seu tempo para este proceso migratorio. Debido a isto, será moi difícil dar marcos de tempo exactos polo tempo que tardará cada parte do proceso. Esta incerteza debe terse en conta na planificación. Por suposto, as doazóns son benvidas para axudar a que isto suceda.
  3. Pode haber desenvolvedores e institucións que financien novas funcións para a serie QGIS 2.x e isto pode afectar o seu traballo. É necesario incluír nos plans e orzamentos destes proxectos unha determinada asignación para afrontar a migración á plataforma QGIS 3.x.
  4. Se o equipo de QGIS traballa nun "cambio total", haberá un tempo relativamente curto durante o cal QGIS será inestable e cambiará constantemente debido ás actualizacións en curso de QGIS 3.0.
  4. Se desenvolves dun xeito "evolutivo", corres o risco de que o desenvolvemento 3.0 poida levar máis tempo a menos que teñas un grupo leal de desenvolvedores traballando nel e preparando o portabilidade.

  Suxestións

Á luz de toda a información anterior, proponse unha das dúas liñas de actuación:

Proposta 1:

Lanzando unha versión provisional 2.16 e logo comezando a traballar na versión 3.0 como prioridade, cunha xanela de desenvolvemento de 8 meses. Os cambios feitos na versión 2.16 buscarán ser compatibles coa versión 3.0 (ver python3 / pytq5).

Proposta 2:

Complicidade xa 3.0 cunha fiestra de duración máis prolongada en QT5, Python 3.0 e PyQt5 e pedir os desenvolvedores a facer o seu traballo en 3.0. Continúa con versións 2.x a intervalos regulares ata que 3.0 estea listo.

Propostas alternativas

Tes algunha proposta alternativa? QGIS está interesado en coñecer posibles alternativas. Se desexa enviar unha proposta, envíe a tim@qgis.org coa materia “Proposta QGIS 3.0”.

O Blog de QGIS, onde saíu esta publicación.