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?

QGis_LogoDi 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 è il set base di librerie in cui QGIS è costruito al livello più alto, stiamo parlando del livello funzionale CORE della piattaforma. Il 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 in fase di sviluppo da parte dei responsabili della libreria Qt e potrebbe avere problemi in termini di funzionalità con alcune piattaforme (ad esempio OS X) e addirittura facilitare la gestione delle versioni binarie (per esempio Debian Testing e la prossima versione Debian "Stretch"). Il processo di portare QGIS al QT5 ha già un passo importante (soprattutto quello che ha fatto Matthias Kuhn) che insieme a Marco Bernasocchi fuma su Android «QField» basato interamente su QT5. Tuttavia, ci sono alcune limitazioni nel lancio del nuovo QT5 a causa del suo impatto su QGIS, in particolare con i widget del browser web (utilizzati principalmente in Composer e anche in 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 cui mantiene la compatibilità API tra le versioni è che devi convivere con le tue opzioni di progettazione a lungo termine. In QGIS viene fatto ogni sforzo per non rompere l'API all'interno di una serie di versioni minori. Rilasciare una versione di QGIS per 3.0 con un'API che non è attuale con l'attuale darà l'opportunità di "pulire la casa" correggendo le cose nell'API con cui siamo in disaccordo. È possibile visualizzare un elenco provvisorio dei file 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:


QGIS 2.14 LTR
QGIS 2.16 ??? QGIS 3.0
Data di rilascio Fine febbraio mesi 4 2.14 ¿mesi Ciclo 8?
note: Aggiornamento del nucleo codice QGIS Python python 3 sia compatibile e supporta PyQt5 (attuazione parziale per la chiave consolle funzionalità esempio, plugin core pitone etc.)
Qt4 Si

Deprecato in Debian Stretch (dovuta in un anno)

(-webkit rimosso)

Non
Qt5 Non

Misses QWebView - nuova sostituzione non su tutte le piattaforme. Misses anche QPainter motore.

Si Si
PyQt4 Si Si Non
PyQt5 Non Si Si
Python 2 Si Si Non
Python 3 Non Si Si
API Cleanup Non Non Si
wrapper
PyQt5 -> PyQt4
~ 90% fornisce la compatibilità all'indietro
Non Si Si
corrente principale binario Sulla base Qt4 Sulla base Qt4 Sulla base Qt5
priorità di finanziamento wrapper Python

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 della versione 3.0 possa richiedere più tempo a meno che tu non abbia un gruppo fedele di sviluppatori che ci lavorano e ti preparano per la migrazione.

    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.

Lascia una risposta

L'indirizzo email non verrà pubblicato.

Questo sito utilizza Akismet per ridurre lo spam. Scopri come vengono elaborati i dati dei tuoi commenti.