QGIS 3.0 - Kako, kdaj in kaj; to pomeni

Mnogi se sprašujejo:

Kdaj bo sproščen QGIS 3.0?

Lansko leto (2015) je projektna skupina začela raziskati, kdaj in kako naj bi bilo sproščeno QGIS 3.0. Obljubili so, glede na objavo iz Anita Graser, da bodo svoje načrte jasno predstavili uporabnikom in razvijalcem, preden bodo lansirali QGIS 3.0. Pred kratkim so poskušali izpostaviti nekatere premisleke glede izdaje QGIS 3.0 in na koncu prispevka imamo priložnost, da predstavimo svoje ideje.

Zakaj 3.0?

Običajno je glavna različica rezervirana za primere, ko se API vaše programske opreme spremeni. Ta prekinitev ni nepomembna odločitev za projekt QGIS, saj imamo na stotisoče uporabnikov, ki so odvisni od QGIS, tako za lastno uporabo kot za storitve, ki se zagotavljajo tretjim osebam.

Občasno prekinjanje API-jev je potrebno, da se prilagodi posodabljanju arhitekture z izboljšanjem pristopov, novih knjižnic in popravkov odločitev v preteklosti.

Kakšne so posledice prekinitve API-ja?

Eden od razlogov, zakaj je to zlom API v QGIS 3.0, je, da bo imel velik vpliv, ki bi lahko prekinil na stotine razvitih vtičnikov, ki ne bi bili več združljivi z novim API-jem, avtorji teh pa bi morali storiti pregled njihovega razvoja, da se zagotovi združljivost z novim API-jem.

Obseg potrebnih sprememb je v veliki meri odvisen od:

• Koliko sprememb API vpliva na trenutno funkcijo.
  V koliko točkah so avtorji pluginov uporabili dele API-ja, ki bi jih spremenili.

• Kaj bodo glavne spremembe za 3.0?

Obstajajo štiri ključna področja, ki jih želite spremeniti v 3.0:

Posodobitev Qt4 na QT5: To je osnovni nabor knjižnic, na katerem je QGIS zgrajen na najvišji ravni, govorimo o CORE-funkcionalni ravni platforme. QT ponuja tudi knjižnice za upravljanje pomnilnika, povezljivost in upravljanje grafike. Qt4 (na katerem trenutno temelji QGIS) trenutno ne razvijajo vzdrževalci knjižnice Qt in ima lahko težave s funkcionalnostjo nekaterih platform (npr. OS X) in celo olajša upravljanje binarnih različic (npr. Debian Testing in naslednja izdaja Debiana "Raztegniti"). Postopek prenosa QGIS v QT5 že ima pomemben napredek (predvsem tisto, kar je naredil Matthias Kuhn), ki skupaj z Marcom Bernasocchijem kadi na Android "QField", ki v celoti temelji na QT5. Vendar pa obstajajo nekatere omejitve pri zagonu novega QT5 zaradi njegovega vpliva na QGIS – zlasti s pripomočki spletnega brskalnika (ki se večinoma uporabljajo v Composerju in tudi na nekaj drugih mestih v QGIS).

Posodobi PyQt4 na PyQt5: To so relativne spremembe jezika Python za Qt, na katerih temelji QGIS Python API. Nastane spremenite QT5 C ++ knjižnice, se tudi pričakuje, da prenese na PyQt5 Python knjižnice, tako da lahko izkoristijo prednosti novega API v Python QT5.
2.7: posodobitev Python 3 na Python Trenutno vse deluje na Pythonu 2.7. Python 3 je najnovejša različica pythona in ga priporočajo tisti, ki vodijo ta projekt. Python 2 je nekoliko nezdružljiv s Pythonom 3 (skoraj sorazmeren z nezdružljivostjo med QGIS 2 in Qgis 3). Številni razvijalci so naredili python Python 3 v veliki meri nazaj združljiv s Python 2, vendar povratna združljivost ni tako dobra.
Izboljšanje samega API-ja QGIS: Ena od težav pri ohranjanju združljivosti API-jev med različicami je ta, da morate dolgo živeti s svojimi oblikovalskimi odločitvami. QGIS se trudi po svojih najboljših močeh, da ne bi prišlo do zloma API-ja v nizu manjših izdaj. Izdaja različice QGIS za 3.0 z API-jem, ki trenutno ni podprt, nam bo dala priložnost, da "počistimo hišo" tako, da v API-ju popravimo stvari, s katerimi nismo skladni. Ogledate si lahko začasni seznam predlagane spremembe za 3.0 API.

Kako podpirati spreminjanje API-ja 3.0

Kot smo že omenili, se bo različica 3.0 zlomila z različico QGIS 2.x in obstaja verjetnost, da se bodo številni vtičniki, obstoječe aplikacije in druge kode, ki temeljijo na trenutnem API-ju, zlomili. Kaj je torej mogoče storiti za ublažitev sprememb? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias in drugi vrhunski razvijalci so iskali načine za ublažitev števila sprememb prekinitev API-ja, hkrati pa še naprej pospeševali kodno bazo QGIS, ki temelji na naslednji generaciji knjižnic in lastnem notranjem API-ju. Na našem zadnjem srečanju usmerjevalnega odbora za projekt QGIS so ga razčlenili skozi različne možnosti. Naslednja tabela povzema tisto, kar je ljubeznivo povzel Matthias Kuhn in ki smo ga v tem članku delno poskušali transliterirati glede na to, kaj objavil v svojem blogu:

Obstajajo dve pomembni stvari, ki morajo upoštevati predlog Matiasa:

V prvi faziDelo je bilo opravljeno v seriji za dokončanje 2.x podporo QT5, PyQt5 uporabo Python 3.0, podpira Qt4, PyQt4 in Python 2.7. To pomeni, da bi vse spremembe, ki v prvi fazi združljiva s starejšimi različicami 2.x. funkcije Python se bodo vključene, se bo predstavil tako, da lahko stari API PyQt4 še vedno uporablja predvsem pri zbiranju proti QT5, PyQt5, Python 3.0. Z uporabo QGIS, zbrane pred Qt4, PyQt4 in Python 2.7 ne bi prekinil združljivosti.
V drugi faziTo bi delovalo za proizvodnjo QGIS 3.0, ki uvaja nov API, popolnoma odstraniti Python 2.7, vključno s podporo za Qt4 in PyQt4. Nove funkcije v Python, ki vstopajo v prvo fazo, se bo ohranila, ob upoštevanju vseh kodo Python in razvoj za 2.x različice QGIS še naprej delati na različicah 3.x v QGIS. Ta faza naj bi se tudi za uvedbo sprememb v API QGIS, ki bi lahko prekinil nekaj vtičnikov. Za rešitev tega problema bo zagotovila smernice aa migracije, da bi poskušali olajšati selitev različic 2.x QGIS 3.x QGIS različice.

Spominjanje emptorja

Obstaja nekaj trikov, ki bi jih bilo treba uvesti, da bi zagotovili, da se migracija v QGIS 3.0 zdi manj boleča.

• 1. SUpoštevati je treba, da čeprav zgoraj opisani pristop skuša minimizirati količino dela na skriptu python v vtičnikih, to ne bo nujno 100%. Najverjetneje bodo primeri, ko je treba kodo spremeniti, v vseh primerih pa jo bo verjetno treba popraviti, da bo še naprej pravilno deloval.
  2. Ni formalno vzpostavljenega finančnega vira, s katerim bi razvijalcem, ki prostovoljno vlagajo čas za ta migracijski proces, plačali. Zaradi tega bo zelo težko natančno določiti časovne okvire, kako dolgo bo trajal posamezen del procesa. To negotovost je treba upoštevati pri načrtovanju. Seveda so donacije dobrodošle, da se to uresniči.
  3. Obstajajo razvijalci in ustanove, ki financirajo nove funkcije za serijo QGIS 2.x, kar lahko vpliva na vaše delo. V načrte in proračune teh projektov je treba vključiti določeno dodelitev za prehod na platformo QGIS 3.x.
  4. Če ekipa QGIS dela na "popolni spremembi", bo QGIS relativno kratek čas nestabilen in se bo nenehno spreminjal zaradi nenehnih posodobitev QGIS 3.0.
  4. Če razvijate na 'evolucijski' način, tvegate, da bo razvoj 3.0 lahko trajal dlje, razen če imate zvesto skupino razvijalcev, ki dela na tem in ga pripravlja na prenos.

  Predlogi

Glede na vse zgoraj navedene informacije je predlagana ena od dveh vrst ukrepov:

1 Predlog:

Sprostite začasno različico 2.16 in nato začnite prednostno delati na različici 3.0 z razvojnim obdobjem 8 mesecev. Spremembe v različici 2.16 bodo skušale biti združljive z različico 3.0 (glej python3 / pytq5).

2 Predlog:

Lunging enkrat 3.0 z bolj razširjeno okno trajanje na QT5, Python 3.0 in PyQt5 in prosi razvijalcem, da opravljajo svoje delo v 3.0. Nadaljujte z različicami 2.x v rednih intervalih, dokler ni pripravljen 3.0.

Alternativni predlogi

Imate alternativni predlog? QGIS želi vedeti o možnih alternativah. Če želite oddati predlog, ga pošljite na tim@qgis.org s predmetom »Predlog QGIS 3.0«.

The Blog QGIS, kjer je prišla ta publikacija.