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 transmitirían claramente aos usuarios e desenvolvedores dos seus plans antes de lanzar QGIS 3.0. Recentemente intentaron expoñer algunhas das consideracións para o lanzamento de QGIS 3.0 e ao final da publicación hai unha oportunidade para que presentemos as nosas ideas.

Por que 3.0?

QGis_LogoNormalmente, unha versión principal está reservada para momentos nos que se fai un gran cambio na API do seu software. Esta ruptura non é unha decisión trivial para o proxecto QGIS xa que somos centos de miles de usuarios que dependen do QGIS, tanto para o seu uso como para o servizo prestado 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 nas que QGIS está construído no nivel superior, estamos falando do nivel funcional CORE da plataforma. O QT tamén ofrece bibliotecas para a xestión de momentos, operacións de conectividade e xestión de gráficos. O Qt4 (no que se basea actualmente QGIS) non está a ser desenvolvido actualmente polos responsables da biblioteca Qt e podería ter problemas en termos de funcionalidades con algunhas plataformas (por exemplo, OS X) e incluso facilitar a xestión de versións binarias. (por exemplo Debian Testing ea seguinte versión de Debian «Stretch»). O proceso de levar QGIS a QT5 xa ten un avance importante (sobre todo o que fixo Matthias Kuhn) que xunto con Marco Bernasocchi fuman no «QField» de Android baseado enteiramente en QT5. Non obstante, hai algunhas limitacións no lanzamento do novo QT5 debido ao seu impacto en QGIS - en particular cos widgets do navegador web (utilizados principalmente no Composer e tamén noutros 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 corre en Python 2.7. Python 3 é a versión máis recente de python e é recomendado por quen dirixe ese proxecto. Python 2 é un pouco incompatible con Python 3 (ata un punto case proporcional á incompatibilidade entre QGIS 2 e Qgis 3). Moitos desenvolvedores fixeron que Python Python 3 sexa en gran medida compatible con versións anteriores de Python 2, pero a compatibilidade inversa non é tan boa.
Mellora da propia QGIS API: Un dos problemas cos que mantén a compatibilidade de API entre as versións é que ten que vivir coas opcións de deseño a longo prazo. En QGIS, fanse todos os esforzos para non romper a API dentro dunha serie de versións menores. Publicar unha versión QGIS para 3.0 cunha API non compatible coa actual dará a oportunidade de "limpar a casa" corrixindo cousas na API que somos coas que non hai conformidade. Podes ver unha lista provisional do documento Cambios propostos para a API 3.0.

Como soportar cambiar a API 3.0

Como xa se mencionou, a versión 3.0 unha ruptura coa versión QGIS 2.x causar e hai a posibilidade de que moitos plugins, aplicacións existentes e outros códigos baséanse na quebra API actual. Entón, que se pode facer para mitigar os cambios? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias e outros desenvolvedores principais foron á procura de formas de mitigar o número de cambios na API dobres mentres aínda avanzar o QGIS código de base basearse na próxima xeración de bibliotecas ea súa propia API interna. Durante a nosa última reunión do Comité Directivo do Proxecto QGIS foi geofumado a través de varias posibilidades. A seguinte táboa resume o que Matthias Kuhn resumiu suavemente e en parte intentaron transliterá neste artigo de acordo co que publicado no teu blog:


QGIS 2.14 LTR
QGIS 2.16 ??? QGIS 3.0
Data de lanzamento Fin de febreiro 4 meses máis tarde 2.14 Ciclo dos meses 8?
Notas Actualiza o código python do núcleo QGIS para ser compatíbel con Python 3 e compatible con PyQt5 (implementación parcial para funcionalidades clave, por exemplo, consola, complementos de Python, etc.)
Qt4 Si

Deprecada en Debian Stretch (debido nun ano)

(elimina a webkit)

si Non
Qt5 Non

Falta QWebView: nova substitución non está en todas as plataformas. Tamén falta QPainter Engine.

Si Si
PyQt4 Si Si Non
PyQt5 Non Si Si
python 2 Si Si Non
python 3 Non Si Si
Limpeza da API Non Non Si
Envolturas
PyQt5 -> PyQt4
Proporciona ~ 90% compatibilidade con versións anteriores
Non Si Si
Binary mainstream Baseado en Qt4 Baseado en Qt4 Baseado en Qt5
Prioridade de financiamento Envoltura de Python

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 salientar que mentres o enfoque descrito anteriormente ten como obxectivo minimizar a cantidade de traballo no script de Python nos complementos, isto non necesariamente estará nun 100%. Probablemente haberá casos nos que o código debe axustarse e, en todo caso, polo menos, probablemente haxa que revisar para asegurarse de que segue funcionando correctamente.
    2. Non existe un recurso financeiro formalmente establecido para pagar aos desenvolvedores que invistan o seu tempo voluntariamente neste proceso de migración. Debido a iso, será moi difícil darlle prazos exactos sobre o tempo que levará cada parte do proceso. Esta incerteza debe ter 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 alí que financian novas funcións para a serie QGIS 2.x e isto pode afectar o seu traballo. Nos plans e orzamentos destes proxectos, debe incluírse algunha asignación para abordar a migración á plataforma 3.x de QGIS.
    4. Se o equipo de QGIS traballa cun "cambio total", haberá un tempo relativamente curto durante o cal QGIS será inestable e en constante cambio debido ás actualizacións en curso de QGIS 3.0.
    4. Se se desenvolve dun xeito "evolutivo", existe o risco de que o desenvolvemento de 3.0 poida levar máis tempo a menos que haxa un grupo leal de desenvolvedores traballando nel e listo para migrar.

    Suxestións

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

Proposta 1:

Deixar unha versión 2.16 provisional e comezar 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 unha proposta alternativa? QGIS está interesado en coñecer as posibles alternativas. Se desexa enviar unha proposta, envíe tim@qgis.org co asunto "QGIS 3.0 Proposal".

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

Deixe un comentario

Enderezo de correo electrónico non será publicado.

Este sitio usa Akismet para reducir o spam. Aprende a procesar os teus datos de comentarios.