QGIS 3.0 - Cum, când și ce; implică

Mulți dintre noi se întreabă:

Când va fi lansat QGIS 3.0?

Anul trecut (2015) echipa de proiect a început să investigheze când și cum a fost lansat QGIS 3.0. Ei au promis, potrivit unui post de la Anita Graser, că vor transmite în mod clar planurile lor utilizatorilor și dezvoltatorilor înainte de a lansa QGIS 3.0. Recent, au încercat să expună unele dintre considerațiile pentru o versiune QGIS 3.0 și la sfârșitul postării avem ocazia să ne prezentăm ideile.

De ce 3.0?

De obicei, o versiune majoră este rezervată pentru momentele în care se face o modificare importantă a API-ului software-ului dvs. Această pauză nu este o decizie banală pentru proiectul QGIS, deoarece suntem sute de mii de utilizatori care depind de QGIS, atât pentru propria noastră utilizare, cât și pentru serviciile furnizate terților.

Ocazional de rupere este nevoie de API pentru a permite actualizarea arhitecturii cu abordări îmbunătățite, noi biblioteci și corecțiile pentru deciziile luate în trecut.

Care sunt consecințele de rupere API?

Un motiv pentru această încălcare a API în QGIS 3.0 este că acesta va avea un impact mare, care ar putea rupe sute de plugin-uri dezvoltate, care nu ar mai fi compatibile cu noul API și autorii acestora trebuie să facă o revizuire a evoluțiilor lor pentru a asigura compatibilitatea cu noul API.

Amploarea modificărilor necesare depinde în mare măsură de:

• Multe modificări API afectează funcționalitatea curentă.
  Cât de multe puncte de plugin-uri autori au folosit părți ale API-ului care s-ar schimba.

• Care sunt principalele modificări la 3.0?

Există patru domenii cheie care sunt în căutarea pentru o schimbare la 3.0:

Qt4 la actualizare QT5: Acesta este setul de bază de biblioteci pe care QGIS este construit la nivel superior, vorbim de nivelul funcțional CORE al platformei. QT oferă, de asemenea, biblioteci pentru gestionarea memoriei, operațiuni de conectivitate și management grafic. Qt4 (pe care se bazează QGIS în prezent) nu este dezvoltat în prezent de către întreținerii bibliotecii Qt și ar putea avea probleme de funcționalitate cu unele platforme (de exemplu OS X) și chiar ușurează gestionarea versiunilor binare (de exemplu, Debian Testing și următoarea versiune Debian). "Întinde"). Procesul de aducere a QGIS la QT5 are deja un avans important (în principal ceea ce a făcut Matthias Kuhn) care împreună cu Marco Bernasocchi fumează pe Android „QField” bazat în întregime pe QT5. Cu toate acestea, există unele limitări în a pune în funcțiune noul QT5 din cauza impactului său asupra QGIS – în special cu widget-urile browserului web (utilizate în principal în Composer și, de asemenea, în alte câteva locuri în QGIS).

PyQt4 la actualizare PyQt5: Acestea sunt modificările relative la limba Python pentru Qt pe care se bazează QGIS Python API. PROVINE schimba biblioteca QT5 C ++, este, de asemenea, de așteptat să transfere la PyQt5 biblioteca Python, astfel încât acestea să poată beneficia de avantajele noului API în Python QT5.
Actualizarea Python Python 2.7 3 la: În prezent, totul rulează pe Python 2.7. Python 3 este cea mai recentă versiune de python și este recomandată de cei care conduc acel proiect. Python 2 este ușor incompatibil cu Python 3 (aproape proporțional cu incompatibilitatea dintre QGIS 2 și Qgis 3). Mulți dezvoltatori au făcut Python Python 3 în mare parte compatibil înapoi cu Python 2, dar compatibilitatea înapoi nu este atât de grozavă.
Îmbunătățirea propriu QGIS API: Una dintre problemele legate de menținerea compatibilității API între versiuni este că trebuie să trăiești cu alegerile tale de design pe termen lung. În QGIS se depun toate eforturile pentru a nu sparge API-ul într-o serie de versiuni minore. Lansarea unei versiuni QGIS pentru 3.0 cu un API neacceptat în prezent ne va oferi o oportunitate de a „curăța casa” prin remedierea lucrurilor din API pe care nu le respectăm. Puteți vedea o listă provizorie a 3.0 a propus modificări pentru API.

Cum să sprijine schimbarea API 3.0

După cum sa menționat deja, versiunea 3.0 se va rupe cu QGIS versiunea 2.x și există șansa ca multe pluginuri, aplicații existente și alte coduri care se bazează pe API-ul actual să se rupă. Deci, ce se poate face pentru a atenua schimbările? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias și alți dezvoltatori de top au căutat modalități de a atenua numărul de modificări ale pauzei API, continuând totodată să avanseze baza de cod QGIS, bazându-se pe următoarea generație de biblioteci și propriul API intern. În cadrul ultimei noastre întâlniri a Comitetului de coordonare a proiectului QGIS, a fost geofumat prin diferite posibilități. Tabelul următor rezumă ceea ce a rezumat cu grație Matthias Kuhn și pe care am încercat parțial să-l transliterăm în acest articol în funcție de ceea ce Ei au publicat pe blog-ul său:

Există două lucruri importante de reținut despre Matthias propunerii:

In prima fazaLucrarea se face în seria pentru a finaliza 2.x sprijin QT5, PyQt5 folosind Python 3.0, sprijinind Qt4, PyQt4 și Python 2.7. Aceasta implică faptul că toate modificările făcute în prima fază ar fi compatibilă cu versiunile anterioare 2.x. Caracteristici Python vor fi încorporate vor fi introduse, astfel încât vechiul API PyQt4 poate fi încă folosit mai ales atunci când sunt compilate împotriva QT5, PyQt5, Python 3.0. Prin utilizarea QGIS compilate împotriva Qt4, PyQt4 și Python 2.7 nu s-ar rupe compatibilitate.
În a doua etapăAr lucra pentru a produce QGIS 3.0, introducerea noului API, complet eliminați Python 2.7, inclusiv suport pentru Qt4 și PyQt4. Noile caracteristici în Python care intră în prima fază va fi menținută, ținând cont de toate codul Python și evoluția pentru versiunile 2.x de QGIS continuă să lucreze la versiunile 3.x ale QGIS. Această fază este, de asemenea, de așteptat să se introducă modificări ale API QGIS care pot rupe unele plugin-uri. Pentru a rezolva acest lucru va oferi îndrumare de migrare aa pentru a încerca să faciliteze migrarea versiunilor 2.x QGIS 3.x QGIS versiuni.

caveat emptor

Există câteva trucuri pentru a fi cerut să se asigure că migrarea la QGIS 3.0 sunet mai puțin dureros.

• 1. STrebuie remarcat faptul că, în timp ce abordarea prezentată mai sus încearcă să minimizeze cantitatea de lucru pe scriptarea python în pluginuri, aceasta nu va fi neapărat 100%. Cel mai probabil vor exista cazuri în care codul trebuie modificat și, în toate cazurile, cel puțin va trebui să fie revizuit pentru a vă asigura că acesta continuă să funcționeze corect.
  2. Nu există o resursă financiară stabilită oficial pentru a plăti dezvoltatorilor care își investesc voluntar timpul pentru acest proces de migrare. Din această cauză, va fi foarte dificil să oferim intervale de timp exacte pentru cât timp va dura fiecare parte a procesului. Această incertitudine trebuie luată în considerare în planificare. Desigur, donațiile sunt binevenite pentru a ajuta la realizarea acestui lucru.
  3. Pot exista dezvoltatori și instituții care finanțează noi funcții pentru seria QGIS 2.x și acest lucru vă poate afecta munca. Este necesar să se includă în planurile și bugetele acestor proiecte, o anumită alocare pentru a face față migrării către platforma QGIS 3.x.
  4. Dacă echipa QGIS lucrează la o „schimbare totală”, va exista un timp relativ scurt în care QGIS va fi instabil și se va schimba constant din cauza actualizărilor în curs de desfășurare la QGIS 3.0.
  4. Dacă dezvoltați într-un mod „evoluționar”, riscați ca dezvoltarea 3.0 să dureze mai mult decât dacă aveți un grup loial de dezvoltatori care lucrează la el și îl pregătesc pentru portare.

  propuneri

Având în vedere toate informațiile de mai sus, una din cele două direcții de acțiune sunt propuse:

Propunerea 1:

Lansați o versiune intermediară 2.16 și apoi începeți să lucrați la versiunea 3.0 ca prioritate, cu o fereastră de dezvoltare de 8 luni. Modificările făcute în versiunea 2.16 vor căuta să fie compatibile cu versiunea 3.0 (vezi python3 / pytq5).

Propunerea 2:

Întinzi o dată 3.0 cu o fereastră de durată mai extinsă pe QT5, Python 3.0 și PyQt5 și cere dezvoltatorilor să facă munca lor în 3.0. Continuați cu versiunile 2.x cu frecvența obișnuită, până când 3.0 este gata.

propuneri alternative

Aveți o propunere alternativă? QGIS este interesat să cunoască posibile alternative. Dacă doriți să trimiteți o propunere, vă rugăm să trimiteți la tim@qgis.org cu subiectul „Propunere QGIS 3.0”.

Ar trebui să urmeze QGIS blog-, Această publicație a venit unde.