QGIS 3.0 - Com, quan i què; implica

Molts ens estem preguntant:

¿Quan es va a alliberar QGIS 3.0?

L'any passat (2015) l'equip del projecte va començar a investigar quan i com s'anava a alliberar QGIS 3.0. Van prometre, d'acord a un post d' Anita Graser, Que anaven a transmetre clarament als usuaris i desenvolupadors dels seus plans abans de fer el llançament de QGIS 3.0. Recentment han tractat d'exposar algunes de les consideracions per a un llançament de QGIS 3.0 i a la fi de l'post hi ha una oportunitat perquè puguem presentar les nostres idees.

Per què 3.0?

Normalment una versió principal està reservat per als temps quan es fa un gran canvi a l'API del seu programari. Aquest trencament no és una decisió trivial per al projecte QGIS ja que som centenars de milers d'usuaris que depenem de QGIS, tant per a ús propi com per a servei prestat a tercers.

De tant en tant trencar l'API és necessària per donar cabuda a l'actualització de l'arquitectura amb la millora dels enfocaments, noves biblioteques i correccions a decisions comesos en el passat.

Quines són les conseqüències de trencar l'API?

Una de les raons per les quals aquest trencament de l'API en QGIS 3.0 és que tindrà un gran impacte, el que podria trencar els centenars de connectors desenvolupats que ja no serien compatible amb la nova API i els autors d'aquests haurien de fer una revisió dels seus desenvolupaments per assegurar compatibilitat amb la nova API.

L'amplitud dels canvis necessaris depèn en gran mesura de:

• Quants canvis a l'API afecten la funcionalitat actual.
  En quants punts els autors de connectors han utilitzat parts de l'API que canviaria.

• Quins seran els principals canvis per 3.0?

Hi ha quatre àrees clau que s'està buscant canviar a 3.0:

Actualització Qt4 cap QT5: Aquest és el conjunt bàsic de les biblioteques on QGIS està construït en top level, parlem del nivell CORE-funcional de la plataforma. El QT també proporciona biblioteques per dur a terme la gestió de momoria, operacions de connectivitat i la gestió de gràfics. El Qt4 (en què QGIS es basa actualment) per ara no està sent desenvolupat pels responsables de la biblioteca Qt i podria tenir problemes quant a funcionalitats amb algunes plataformes (per exemple, OS X) i fins i tot facilitar la gestió de versions binàries (per exemple Debian Testing i la propera versió de Debian “Stretch”). El procés de portar QGIS a QT5 ja té un avenç important (principalment el que ha fet Matthias Kuhn) que juntament amb Marco Bernasocchi fumen sobre l'Android “QField” basat totalment en QT5. No obstant això, hi ha algunes limitacions a posar en marxa la nova QT5 pel seu impacte a QGIS – en particular amb els ginys de navegadors web (utilitzats principalment al Composer i també alguns altres llocs a QGIS).

Actualització PyQt4 a PyQt5: Aquests són els canvis relatius al llenguatge Python per Qt en què es basa l'API Python de QGIS. Es planteja canviar la biblioteca d'QT5 C ++, també s'espera traslladar a la biblioteca python a PyQt5 perquè es puguin treure profit a les bondats de la nova API QT5 en Python.
Actualitzant Python 2.7 a Python 3: Actualment tot corre sobre Python 2.7. Python 3 és l'última versió de python i és recomanat pels que lideren aquell projecte. Python 2 és lleugerament incompatible amb Python 3 (en una mesura gairebé proporcional a la incompatibilitat que hi haurà entre QGIS 2 i QGIS 3). Molts desenvolupadors han fet python Python 3 en gran mesura compatible amb versions anteriors de Python 2, però la compatibilitat en sentit invers no és tan bona.
La millora de la pròpia API de QGIS: Un dels problemes amb què manté la compatibilitat API entre versions és que cal viure amb les opcions de disseny per a un llarg termini. A QGIS es fa tot el possible per no trencar l'API dins d'una sèrie de llançaments de menor importància. Alliberar una versió QGIS per a 3.0 amb una API no compatible amb allò actual donarà una oportunitat de “netejar la casa” mitjançant la fixació de les coses a l'API que estem amb la qual hi ha inconformitat. Es pot veure una llista provisional dels canvis proposats per l'API 3.0.

Com suportar el canvi de l'API 3.0

Com ja es va esmentar, la versió 3.0 es provocarà una ruptura amb la versió 2.x de QGIS i hi ha la possibilitat que molts plugins, aplicacions existents i altres codis que es basen en l'API actual es trenquin. Llavors, què es pot fer per mitigar els canvis? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias i altres desenvolupadors principals han estat buscant maneres de mitigar el nombre de canvis de ruptura API mentre segueix avançant el codi base QGIS estar basat en la propera generació de biblioteques i la seva pròpia API interna. Durant la nostra última reunió de Comitè Directiu de el Projecte QGIS es geofumó a través de diverses possibilitats. La següent taula resumeix el que gentilment va resumir Matthias Kuhn i que en part hem intentat transliterar en aquest article d'acord amb el que van publicar al seu bloc:

Hi ha dues coses importants a tenir en compte sobre la proposta de Matías:

En la primera fase, El treball es fa en la sèrie 2.x per completar el suport a QT5, PyQt5, usant Python 3.0, donant suport a Qt4, PyQt4 i Python 2.7. Això implica que tots els canvis realitzats en la primera fase serien compatibles amb les versions 2.x anteriors. S'incorporaran funcionalitats de Python s'introduiran de manera que l'antiga API PyQt4 encara pot ser utilitzat sobretot quan es compila contra QT5, PyQt5, Python 3.0. En usar QGIS compilats contra Qt4, PyQt4 i Python 2.7 no hi hauria ruptura compatibilitat.
En la segona fase, Es treballaria per produir QGIS 3.0, introduint la nova API, la s'eliminarà totalment Python 2.7, inclòs el suport per a Qt4 i PyQt4. Les noves de python que s'introdueixin en la primera fase es mantindran, tenint en compte que tot el codi python i desenvolupaments per a versions 2.x de QGIS continuaran treballant en les versions 3.x de QGIS. En aquesta fase s'espera també introduir els canvis en l'API QGIS que pot trencar alguns plugins. Per fer front a això es va aa proporcionar una guia de migració per tractar de facilitar el procés de migració de les versions 2.x QGIS a les versions 3.x QGIS.

caveat emptor

Hi ha un parell de trucs que s'han de plantejar per assegurar que la migració a QGIS 3.0 soni menys dolorós.

• 1. Si de destacar que mentre que l'enfocament establerta dalt tracta de minimitzar la quantitat de treball existent en scripting sobre python en els connectors, això no serà necessàriament en un 100%. Hi haurà molt probablement els casos en què el codi ha de ser ajustat i en tots els casos a el menys, és probable que hagi de ser revisat per tal d'assegurar-se que segueix funcionant correctament.
  2. No hi ha recurs financer formalment establert per pagar als desenvolupadors que inverteixen voluntàriament el seu temps per a aquest procés de migració. A causa d'això, serà molt difícil donar terminis exactes de quant temps prendrà cada part de l'procés. S'ha de tenir en compte aquesta incertesa en la planificació. Per descomptat s'obre la benvinguda a donacions per ajudar a que això passi.
  3. Hi pot haver desenvolupadors i institucions per aquí que estan finançant noves característiques per a la sèrie 2.x QGIS i això pot afectar la seva feina. Cal incloure en els plans i pressupostos d'aquests projectes, certa assignació per fer front a la migració a la plataforma 3.x de QGIS.
  4. Si l'equip de QGIS treballa sobre un “canvi total”, hi haurà un temps relativament curt durant el qual QGIS estarà inestable i en canvi constant a causa de les actualitzacions en curs cap a QGIS 3.0.
  4. Si es desenvolupa de manera “evolutiva”', es corre el risc que el desenvolupament 3.0 pot trigar més temps a no ser que hi hagi un grup fidel dels desenvolupadors que treballen sobre això i aconseguir que estigui llest per migrar.

  propostes

A la llum de tota la informació anterior, es proposa una de les dues línies d'acció:

Proposta 1:

Alliberar una versió provisional 2.16 i després començar a treballar en la versió 3.0 com a prioritat, amb una finestra de desenvolupament de 8 mesos. Els canvis fets en la versió 2.16 buscaran ser compatibles amb la versió 3.0 (veure python3 / pytq5).

Proposta 2:

Llançar d'una vegada a 3.0 amb una finestra de durada més estesa sobre QT5, Python 3.0 i PyQt5 i, demanar als desenvolupadors fer la seva feina en 3.0. Continuar amb les versions 2.x amb la freqüència habitual fins que 3.0 estigui a punt.

propostes alternatives

Té una proposta alternativa? A QGIS li interessa saber de possibles alternatives. Si desitja presentar una proposta, si us plau enviar a tim@qgis.org amb l'assumpte “QGIS 3.0 Proposal”.

Convé seguir el bloc de QGIS, D'on va sortir aquesta publicació.