QGIS 3.0 - Come, quando e cosa; implica

Molti di noi si chiedono:

Quando verrà rilasciato QGIS 3.0?

L'anno scorso (2015) il team del progetto ha iniziato a indagare su quando e come QGIS 3.0 avrebbe dovuto essere rilasciato. Hanno promesso, secondo un post di Anita Graser, che avrebbero comunicato chiaramente i loro piani a utenti e sviluppatori prima di lanciare QGIS 3.0. Recentemente hanno cercato di esporre alcune considerazioni per una versione di QGIS 3.0 e alla fine del post c'è un'opportunità per noi di presentare le nostre idee.

Perché 3.0?

Di solito una versione principale è riservata ai momenti in cui viene apportata una grande modifica all'API del software. Questa interruzione non è una decisione banale per il progetto QGIS poiché siamo centinaia di migliaia di utenti che dipendono da QGIS, sia per il nostro uso che per i servizi forniti a terzi.

Di tanto in tanto rompendo l'API è necessaria per accogliere l'aggiornamento all'architettura con approcci migliorate, nuove librerie e correzioni a decisioni prese in passato.

Quali sono le conseguenze di rompere l'API?

Una ragione per cui tale violazione delle API in QGIS 3.0 è che avrà un grande impatto, che potrebbe rompere centinaia di plugin sviluppati, che non sarebbero più compatibili con la nuova API e di questi autori hanno a che fare una revisione dei loro sviluppi per garantire la compatibilità con la nuova API.

La portata dei cambiamenti necessari dipende in gran parte:

• Molti cambiamenti API influenzano la funzionalità corrente.
  Come molti punti plugin autori hanno utilizzato parti della API che avrebbe cambiato.

• Quali sono le principali modifiche apportate 3.0?

Ci sono quattro aree chiave che sono alla ricerca di cambiamento a 3.0:

Qt4 di aggiornamento QT5: Questo è l'insieme base di librerie su cui QGIS è costruito a livello superiore, parliamo del livello CORE-funzionale della piattaforma. QT fornisce anche librerie per eseguire la gestione della memoria, le operazioni di connettività e la gestione della grafica. Qt4 (su cui QGIS è attualmente basato) non è attualmente sviluppato dai manutentori della libreria Qt e potrebbe avere problemi di funzionalità con alcune piattaforme (es. OS X) e persino rendere più semplice la gestione delle versioni binarie (es. Debian Testing e la prossima versione di Debian "Stirata"). Il processo di portare QGIS su QT5 ha già un importante anticipo (soprattutto quello che ha fatto Matthias Kuhn) che insieme a Marco Bernasocchi fuma sul "QField" Android basato interamente su QT5. Tuttavia, ci sono alcune limitazioni nel rendere operativo il nuovo QT5 a causa del suo impatto su QGIS, in particolare con i widget del browser Web (utilizzati principalmente in Composer e anche in alcuni altri posti in QGIS).

PyQt4 di aggiornamento PyQt5: Queste sono le relative modifiche al linguaggio Python per Qt su cui si basa l'API Python QGIS. Nasce cambiare la biblioteca QT5 C ++, è previsto anche per il trasferimento alla libreria python PyQt5 in modo che possano sfruttare i vantaggi della nuova API in Python QT5.
Aggiornamento Python Python 2.7 3 a: Attualmente tutto gira su Python 2.7. Python 3 è l'ultima versione di python ed è consigliato da coloro che guidano quel progetto. Python 2 è leggermente incompatibile con Python 3 (quasi proporzionale all'incompatibilità tra QGIS 2 e Qgis 3). Molti sviluppatori hanno reso Python Python 3 ampiamente compatibile con Python 2, ma la compatibilità con le versioni precedenti non è eccezionale.
Migliorare la propria API QGIS: Uno dei problemi con il mantenimento della compatibilità delle API tra le versioni è che devi convivere con le tue scelte di progettazione a lungo termine. In QGIS viene fatto ogni sforzo per non interrompere l'API in una serie di rilasci minori. Il rilascio di una versione di QGIS per 3.0 con un'API non attualmente supportata ci darà l'opportunità di "pulire casa" risolvendo cose nell'API con cui non siamo conformi. È possibile visualizzare un elenco provvisorio di 3.0 proposto modifiche alle API.

Come sostenere cambiare l'API 3.0

Come già accennato, la versione 3.0 non funzionerà con la versione 2.x di QGIS e c'è la possibilità che molti plugin, applicazioni esistenti e altro codice che si basano sull'API corrente non funzionino. Quindi cosa si può fare per mitigare i cambiamenti? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias e altri importanti sviluppatori hanno cercato modi per mitigare il numero di modifiche alle interruzioni delle API pur continuando a far avanzare la base di codice QGIS basata sulla prossima generazione di librerie e sulla propria API interna. Durante il nostro ultimo incontro del Comitato direttivo del progetto QGIS è stato geofumato attraverso varie possibilità. La tabella seguente riassume ciò che Matthias Kuhn ha graziosamente riassunto e che abbiamo in parte cercato di traslitterare in questo articolo secondo quanto Hanno pubblicato sul suo blog:

Ci sono due cose importanti da notare sui Matthias proposta:

Nella prima faseIl lavoro è svolto in serie per completare 2.x supporto QT5, PyQt5 utilizzando Python 3.0, sostenendo Qt4, PyQt4 e Python 2.7. Ciò implica che tutte le modifiche apportate nella prima fase sarebbero compatibili con le versioni precedenti 2.x. caratteristiche pitone saranno incorporati, saranno introdotti in modo che il vecchio API PyQt4 può ancora essere utilizzato specialmente se compilato contro QT5, PyQt5, Python 3.0. Utilizzando QGIS compilati contro Qt4, PyQt4 e Python 2.7 non sarebbe rompere la compatibilità.
Nella seconda faseSarebbe lavorare per produrre QGIS 3.0, introducendo la nuova API, rimuovere completamente il pitone 2.7, incluso il supporto per Qt4 e PyQt4. Le nuove funzionalità di pitone che entrano nella prima fase saranno mantenute, tenendo conto di tutto il codice Python e sviluppi per versioni 2.x di QGIS continuare a lavorare sulle versioni 3.x di QGIS. Si prevede anche questa fase di introdurre modifiche API QGIS che potrebbero rompere alcuni plugin. Per far fronte a questo fornirà una guida di migrazione aa cercare di facilitare la migrazione delle versioni 2.x QGIS QGIS 3.x versioni.

Caveat emptor

Ci sono alcuni trucchi per essere chiesto di assicurare che la migrazione verso QGIS 3.0 suono meno doloroso.

• 1. SVa notato che mentre l'approccio esposto sopra cerca di ridurre al minimo la quantità di lavoro sullo scripting Python nei plugin, questo non sarà necessariamente al 100%. Molto probabilmente ci saranno casi in cui il codice deve essere modificato e, almeno in tutti i casi, dovrà essere probabilmente rivisto per assicurarsi che continui a funzionare correttamente.
  2. Non esistono risorse finanziarie formalmente stabilite per pagare gli sviluppatori che investono volontariamente il loro tempo per questo processo di migrazione. Per questo motivo, sarà molto difficile fornire dei tempi esatti per quanto tempo richiederà ciascuna parte del processo. Questa incertezza deve essere presa in considerazione nella pianificazione. Ovviamente le donazioni sono benvenute per aiutare a realizzare questo obiettivo.
  3. Potrebbero esserci sviluppatori e istituzioni là fuori che stanno finanziando nuove funzionalità per la serie QGIS 2.xe questo potrebbe influenzare il tuo lavoro. È necessario includere nei piani e nei budget di questi progetti, una certa dotazione per affrontare la migrazione alla piattaforma QGIS 3.x.
  4. Se il team di QGIS lavora su un "cambiamento totale", ci sarà un tempo relativamente breve durante il quale QGIS sarà instabile e cambierà costantemente a causa degli aggiornamenti in corso a QGIS 3.0.
  4. Se sviluppi in modo "evolutivo", corri il rischio che lo sviluppo 3.0 possa richiedere più tempo a meno che tu non abbia un gruppo fedele di sviluppatori che ci lavora e lo prepara per il port.

  Proposte

Alla luce di tutte le informazioni di cui sopra, una delle due linee di azione sono proposti:

proposta 1:

Rilascia una versione provvisoria 2.16 e poi inizia a lavorare sulla versione 3.0 come priorità, con una finestra di sviluppo di 8 mesi. Le modifiche apportate nella versione 2.16 cercheranno di essere compatibili con la versione 3.0 (vedere python3 / pytq5).

proposta 2:

Lunging volta 3.0 con una finestra di durata più estesa sul QT5, Python 3.0 e PyQt5 e chiedere agli sviluppatori di fare il loro lavoro in 3.0. Continuare con le versioni 2.x con la solita frequenza fino a quando 3.0 è pronto.

proposte alternative

Hai una proposta alternativa? QGIS è interessato a conoscere le possibili alternative. Se vuoi inviare una proposta, inviala a tim@qgis.org con oggetto “Proposta QGIS 3.0”.

Dovrebbero seguire la blog QGIS, Dove è venuto questa pubblicazione.