QGIS 3.0 - Hvordan, når og hva; det innebærer

Mange av oss spør:

Når vil QGIS 3.0 bli utgitt?

I fjor (2015) begynte prosjektgruppen å undersøke når og hvordan QGIS 3.0 skulle bli utgitt. De lovet, ifølge et innlegg fra Anita Graser, at de kom til å formidle planene sine tydelig til brukere og utviklere før de lanserte QGIS 3.0. De har nylig prøvd å avsløre noen av hensynene til en QGIS 3.0-utgivelse, og på slutten av innlegget er det en mulighet for oss å presentere våre ideer.

Hvorfor 3.0?

Vanligvis er en hovedversjon reservert for tider når det gjøres en stor endring i programvarens API. Dette bruddet er ikke en triviell beslutning for QGIS-prosjektet siden vi er hundretusener av brukere som er avhengige av QGIS, både for eget bruk og for tjenester som leveres til tredjeparter.

Av og bryte API er nødvendig for å imøtekomme oppdatere arkitektur med forbedrede metoder, nye biblioteker og rettelser til vedtak gjort i fortiden.

Hva er konsekvensene av å bryte API?

En grunn til at dette brudd på API i QGIS 3.0 er at det vil ha en stor innvirkning, noe som kunne bryte hundrevis av utviklede plugins som ikke lenger vil være kompatibel med den nye API og forfatterne av disse har å gjøre en gjennomgang av dens utvikling for å sikre kompatibilitet med den nye API.

Omfanget av de endringene som trengs, avhenger i stor grad på:

• Mange API endringene påvirker dagens funksjonalitet.
  Hvor mange poeng plugins forfattere har brukt deler av API som ville endre.

• Hva er de viktigste endringene i 3.0?

Det er fire viktige områder som er ute etter endring på 3.0:

Qt4 til QT5 oppdatering: Dette er det grunnleggende settet med biblioteker som QGIS er bygget på toppnivå, vi snakker om plattformens CORE-funksjonelle nivå. QT tilbyr også biblioteker for å utføre minneadministrasjon, tilkoblingsoperasjoner og grafikkbehandling. Qt4 (som QGIS for øyeblikket er basert på) utvikles foreløpig ikke av Qt-bibliotekets vedlikeholdere og kan ha funksjonsproblemer med enkelte plattformer (f.eks. OS X) og til og med gjøre det enklere å administrere binære versjoner (f.eks. Debian Testing og neste Debian-utgivelse "Tøye ut"). Prosessen med å bringe QGIS til QT5 har allerede et viktig fremskritt (hovedsakelig det Matthias Kuhn har gjort) som sammen med Marco Bernasocchi røyker på Android "QField" helt basert på QT5. Det er imidlertid noen begrensninger for å få den nye QT5 i drift på grunn av dens innvirkning på QGIS – spesielt med nettleserwidgets (hovedsakelig brukt i Composer og også noen andre steder i QGIS).

PyQt4 til PyQt5 oppdatering: Disse endringene er knyttet til Python språket for Qt i QGIS Python API er basert på. Oppstår endre QT5 C ++ bibliotek, forventes også å overføre til PyQt5 python-biblioteket, slik at de kan dra nytte av fordelene med den nye API i Python QT5.
Oppdatering Python Python 2.7 3 til: Foreløpig kjører alt på Python 2.7. Python 3 er den siste versjonen av python og anbefales av de som leder det prosjektet. Python 2 er litt inkompatibel med Python 3 (nesten proporsjonal med inkompatibiliteten mellom QGIS 2 og Qgis 3). Mange utviklere har gjort python Python 3 stort sett bakoverkompatibel med Python 2, men bakoverkompatibilitet er ikke så bra.
Forbedre QGIS egen API: Et av problemene med å opprettholde API-kompatibilitet mellom versjoner er at du må leve med designvalgene dine på lang sikt. Alt gjøres i QGIS for ikke å bryte API-en i en rekke mindre utgivelser. Å slippe en QGIS-versjon for 3.0 med en API som for øyeblikket ikke støttes, vil gi oss en mulighet til å "rydde hus" ved å fikse ting i APIen som vi ikke er kompatible med. Du kan se en foreløpig liste over 3.0 forslag til endringer i API.

Hvordan støtte endre 3.0 API

Som allerede nevnt vil versjon 3.0 bryte med QGIS versjon 2.x, og det er en sjanse for at mange plugins, eksisterende applikasjoner og annen kode som er basert på gjeldende API vil bryte. Så hva kan gjøres for å redusere endringene? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias og andre topputviklere har sett etter måter å redusere antall API-endringer mens de fortsetter å fremme QGIS-kodebasen som er basert på neste generasjon biblioteker og sin egen interne API. Under vårt siste møte i QGIS Project Steering Committee ble det geofummet gjennom ulike muligheter. Den følgende tabellen oppsummerer hva Matthias Kuhn nådig oppsummerte, og som vi delvis har prøvd å omskrive i denne artikkelen etter hva De publisert på bloggen sin:

Det er to viktige ting å merke seg om forslaget Matthias:

I den første fasenArbeidet er gjort i serie for å fullføre 2.x støtte QT5, PyQt5 Python 3.0, som støtter Qt4, PyQt4 og Python 2.7. Dette innebærer at alle endringer som er gjort i den første fasen vil være kompatibel med tidligere versjoner 2.x. Python funksjoner vil bli innarbeidet vil bli innført, slik at den gamle API PyQt4 fortsatt kan benyttes spesielt når kompilert mot QT5, PyQt5, Python 3.0. Ved å bruke QGIS kompilert mot Qt4, PyQt4 og Python 2.7 ville ikke bryte kompatibilitet.
I den andre fasenDet ville fungere for å produsere QGIS 3.0, innføring av den nye API fjerne helt Python 2.7, inkludert støtte for Qt4 og PyQt4. Nye funksjoner i python som kommer inn i første fase vil bli opprettholdt, tar hensyn til alle python kode og utviklingen for 2.x versjoner av QGIS fortsette å arbeide på 3.x versjoner av QGIS. Denne fasen er også forventet å innføre endringer i QGIS API som kan brekke noen programtillegg. For å løse dette vil gi veiledning aa migrasjon for å prøve å legge til rette for migrasjon av versjonene 2.x QGIS 3.x QGIS versjoner.

forbeholdet emptor

Det finnes noen triks for å bli bedt om å sikre at overgangen til QGIS 3.0 høres mindre smertefull.

• 1. SDet bør bemerkes at mens fremgangsmåten som er beskrevet ovenfor prøver å minimere mengden arbeid med python-skripting i plugins, vil dette ikke nødvendigvis være 100%. Det vil mest sannsynlig være tilfeller der koden må finjusteres, og i alle tilfeller i det minste vil den sannsynligvis måtte revideres for å sikre at den fortsetter å fungere skikkelig.
  2. Det er ingen formelt etablert økonomisk ressurs for å betale utviklere som frivillig investerer tiden sin for denne migrasjonsprosessen. På grunn av dette vil det være veldig vanskelig å gi nøyaktige tidsrammer for hvor lang tid hver del av prosessen vil ta. Denne usikkerheten må tas i betraktning i planleggingen. Naturligvis er donasjoner velkomne til å bidra til at dette skjer.
  3. Det kan være utviklere og institusjoner der ute som finansierer nye funksjoner for QGIS 2.x-serien, og dette kan påvirke arbeidet ditt. Det er nødvendig å inkludere en viss tildeling i planene og budsjettene til disse prosjektene for å møte migrasjonen til QGIS 3.x-plattformen.
  4. Hvis QGIS-teamet jobber med en "total endring", vil det være en relativt kort tid hvor QGIS vil være ustabil og i stadig endring på grunn av pågående oppdateringer til QGIS 3.0.
  4. Hvis du utvikler på en "evolusjonær" måte, risikerer du at 3.0-utvikling kan ta lengre tid med mindre du har en lojal gruppe utviklere som jobber med det og gjør det klart til portering.

  Forslag

I lys av alle de ovennevnte opplysninger, er en av to kurs av handlingen foreslått:

1 forslag:

Slipp en midlertidig versjon 2.16, og begynn deretter å jobbe med versjon 3.0 som en prioritet, med et utviklingsvindu på 8 måneder. Endringer i versjon 2.16 vil være kompatible med versjon 3.0 (se python3 / pytq5).

2 forslag:

Lonsjering gang 3.0 med en mer utvidet varighet vindu på QT5, Python 3.0 og PyQt5 og be utviklere å gjøre sitt arbeid i 3.0. Fortsett med 2.x versjoner med vanlig frekvens inntil 3.0 er klar.

alternative forslag

Har du et alternativt forslag? QGIS er interessert i å vite om mulige alternativer. Hvis du vil sende inn et forslag, kan du sende til tim@qgis.org med emnet "QGIS 3.0 Proposal".

Bør følge QGIS bloggen: Hvor kom denne publikasjonen.