QGIS 3.0 - Hvordan, hvornår og hvad; det indebærer

Mange af os undrer os:

Hvornår udkommer QGIS 3.0?

Sidste år (2015) begyndte projektteamet at undersøge, hvornår og hvordan QGIS 3.0 skulle udgives. Det lovede de ifølge et opslag af Anita Graser, som de klart skulle kommunikere til brugere og udviklere om deres planer, før de lavede QGIS 3.0-udgivelsen. De har for nylig forsøgt at redegøre for nogle af overvejelserne for en QGIS 3.0-udgivelse, og i slutningen af ​​indlægget er der mulighed for, at vi kan præsentere vores ideer.

Hvorfor 3.0?

Typisk er en større udgivelse reserveret til tidspunkter, hvor du foretager en stor ændring af din softwares API. Denne pause er ikke en triviel beslutning for QGIS-projektet, da vi er hundredtusindvis af brugere, der er afhængige af QGIS, både til vores eget brug og til tjenester leveret til tredjeparter.

Af og til er det nødvendigt at bryde API'en for at imødekomme opdatering af arkitekturen med forbedrede tilgange, nye biblioteker og rettelser til tidligere beslutninger.

Hvad er konsekvenserne af at bryde API'en?

En af grundene til, at denne API bryder ind i QGIS 3.0, er, at den vil have en enorm indvirkning, som kan bryde de hundredvis af udviklede plugins, som ikke længere ville være kompatible med den nye API, og forfatterne af disse ville være nødt til at lave en gennemgang af dine udviklinger for at sikre kompatibilitet med den nye API.

Omfanget af nødvendige ændringer afhænger i høj grad af:

• Hvor mange ændringer af API'en påvirker den nuværende funktionalitet.
  På hvilke punkter har plugin-forfattere brugt dele af API'en, som jeg ville ændre.

• Hvad bliver de vigtigste ændringer for 3.0?

Der er fire nøgleområder, vi ønsker at ændre i 3.0:

Qt4 opgradering til QT5: Dette er det grundlæggende sæt af biblioteker, som QGIS er bygget på på øverste niveau, vi taler om platformens CORE-funktionelle niveau. QT leverer også biblioteker til at udføre hukommelsesstyring, forbindelsesoperationer og grafikstyring. Qt4 (som QGIS i øjeblikket er baseret på) udvikles i øjeblikket ikke af de ansvarlige for Qt-biblioteket og kan have funktionelle problemer med nogle platforme (for eksempel OS X) og kan endda lette administrationen af ​​binære versioner. (for eksempel Debian Test og den næste version af Debian "Stretch"). Processen med at bringe QGIS til QT5 har allerede et vigtigt fremskridt (hovedsageligt hvad Matthias Kuhn har gjort), som sammen med Marco Bernasocchi arbejder på Android "QField" udelukkende baseret på QT5. Der er dog nogle begrænsninger ved udrulning af den nye QT5 på grund af dens indvirkning på QGIS – især med webbrowser-widgets (hovedsageligt brugt i Composer og også nogle andre steder i QGIS).

Opdater PyQt4 til PyQt5: Dette er ændringerne relateret til Python-sproget for Qt, som QGIS Python API er baseret på. Det foreslås at ændre QT5 C++ biblioteket, det forventes også at flytte python biblioteket til PyQt5, så fordelene ved det nye QT5 API i Python kan udnyttes.
Opgradering af Python 2.7 til Python 3: Alt kører i øjeblikket oven på Python 2.7. Python 3 er den nyeste version af python og anbefales af dem, der leder det projekt. Python 2 er lidt inkompatibel med Python 3 (næsten proportional med inkompatibiliteten mellem QGIS 2 og Qgis 3). Mange udviklere har gjort Python 3 stort set bagudkompatibel med Python 2, men bagudkompatibiliteten er ikke så god.
Forbedring af selve QGIS API: Et af problemerne med at opretholde API-kompatibilitet mellem versioner er, at du skal leve med dine designvalg på lang sigt. I QGIS gøres alt for ikke at bryde API'en inden for en række mindre udgivelser. Frigivelse af en QGIS-version til 3.0 med en API, der i øjeblikket ikke understøttes, vil give dig mulighed for at "rense hus" ved at rette de ting i API'en, som du ikke er tilfreds med. Du kan se en foreløbig liste over Foreslåede ændringer til API 3.0.

Sådan understøttes API 3.0-ændringen

Som allerede nævnt vil version 3.0 bryde med QGIS version 2.x, og der er mulighed for, at mange plugins, eksisterende applikationer og anden kode, der er afhængig af den nuværende API, vil bryde. Så hvad kan der gøres for at afbøde ændringerne? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias og andre kerneudviklere har ledt efter måder at afbøde antallet af API-brudsændringer, mens de fortsætter med at fremme QGIS-kodebasen, der er baseret på den næste generation af biblioteker og dens egen interne API. Under vores sidste møde i QGIS Project Steering Committee georøg vi forskellige muligheder igennem. Følgende tabel opsummerer, hvad Matthias Kuhn venligt opsummerede, og som vi til dels har forsøgt at translitterere i denne artikel efter, hvad de udgav på deres blog:

Der er to vigtige ting at huske på om Matías' forslag:

i den første fase, arbejdes der i 2.x-serien for at fuldføre understøttelsen af ​​QT5, PyQt5, ved hjælp af Python 3.0, der understøtter Qt4, PyQt4 og Python 2.7. Dette indebærer, at alle ændringer foretaget i den første fase ville være bagudkompatible med 2.x-versioner. Python-funktionaliteter vil blive introduceret, så det gamle PyQt4 API stadig kan bruges, især ved kompilering mod QT5, PyQt5, Python 3.0. Ved at bruge QGIS kompileret mod Qt4, PyQt4 og Python 2.7 ville der ikke være nogen kompatibilitetsbrud.
I anden fase, ville der blive arbejdet på at producere QGIS 3.0, introducerer den nye API, Python 2.7 vil blive fuldstændig fjernet, inklusive understøttelse af Qt4 og PyQt4. De nye python-funktionaliteter introduceret i første fase vil blive vedligeholdt under hensyntagen til, at al python-kode og udviklinger til version 2.x af QGIS vil fortsætte med at fungere i version 3.x af QGIS. I denne fase forventes det også at introducere ændringer til QGIS API, der kan ødelægge nogle plugins. For at løse dette, vil der blive leveret en migreringsvejledning for at forsøge at lette migreringsprocessen fra QGIS version 2.x til QGIS version 3.x.

Caveat

Der er et par tricks at overveje for at sikre, at migrering til QGIS 3.0 lyder mindre smertefuldt.

• 1. SDet skal bemærkes, at selvom den ovenfor beskrevne tilgang forsøger at minimere mængden af ​​python scripting arbejde involveret i plugins, vil dette ikke nødvendigvis være 100%. Der vil højst sandsynligt være tilfælde, hvor koden skal justeres, og i alle tilfælde skal den sandsynligvis kontrolleres for at sikre, at den stadig fungerer korrekt.
  2. Der er ingen formelt etableret økonomisk ressource til at betale udviklere, der frivilligt investerer deres tid i denne migreringsproces. På grund af dette bliver det meget vanskeligt at give nøjagtige tidslinjer for, hvor lang tid hver del af processen vil tage. Denne usikkerhed skal tages med i planlægningen. Donationer er naturligvis velkomne til at hjælpe med at få dette til at ske.
  3. Der kan være udviklere og institutioner derude, som finansierer nye funktioner til QGIS 2.x-serien, og dette kan påvirke dit arbejde. Det er nødvendigt at inkludere en vis allokering i planerne og budgetterne for disse projekter for at klare migreringen til QGIS 3.x-platformen.
  4. Hvis QGIS-teamet arbejder på en "turnaround", vil der være relativt kort tid, hvor QGIS vil være ustabil og konstant ændre sig på grund af løbende opdateringer til QGIS 3.0.
  4. Hvis du udvikler på en 'evolutionær' måde, risikerer du, at 3.0-udvikling kan tage længere tid, medmindre der er en loyal gruppe af udviklere, der arbejder på det og gør det klar til at migrere.

  Forslagene

I lyset af alle de tidligere oplysninger foreslås en af ​​de to handlingslinjer:

1 Forslag:

Frigiv en midlertidig version 2.16 og begynd derefter at arbejde på version 3.0 som en prioritet med et 8-måneders udviklingsvindue. Ændringer foretaget i version 2.16 vil søge at være kompatible med version 3.0 (se python3/pytq5).

2 Forslag:

Slip det hele på én gang til 3.0 med et længere levetid på QT5, Python 3.0 og PyQt5, og bed udviklere om at udføre deres arbejde i 3.0. Fortsæt med 2.x versioner som normalt, indtil 3.0 er klar.

Alternative forslag

Har du et alternativt forslag? QGIS er interesseret i at vide om mulige alternativer. Hvis du ønsker at indsende et forslag, så send venligst til tim@qgis.org med emnet "QGIS 3.0 Proposal".

Det er tilrådeligt at følge QGIS blog, hvor dette indlæg kom fra.