QGIS 3.0 - Hur, när och vad; det antyder

Många frågar oss själva:

När kommer QGIS 3.0 att släppas?

Förra året (2015) började projektgruppen undersöka när och hur QGIS 3.0 skulle släppas. De lovade, enligt ett inlägg från Anita Graser, att de tydligt skulle förmedla sina planer till användare och utvecklare innan de lanserade QGIS 3.0. De har nyligen försökt avslöja några av övervägandena för en QGIS 3.0-utgåva och i slutet av inlägget finns det en möjlighet för oss att presentera våra idéer.

Varför 3.0?

QGis_LogoVanligtvis är en större version reserverad för tider då en stor förändring görs i programvarans API. Denna paus är inte ett trivialt beslut för QGIS-projektet eftersom vi är hundratusentals användare som är beroende av QGIS, både för eget bruk och för tjänster som tillhandahålls till tredje part.

Ibland bryts API: n för att tillgodose uppdatering av arkitekturen med förbättringar av tillvägagångssätt, nya bibliotek och korrigeringar av tidigare beslut.

Vilka är konsekvenserna av att bryta API: n?

En anledning till detta brott mot API qgis 3.0 är att det kommer att ha en stor inverkan, som kunde bryta hundratals utvecklade plugins som inte längre skulle vara förenlig med den nya API och författarna av dessa har att göra en översyn av deras utveckling för att säkerställa kompatibilitet med det nya API.

Omfattningen av nödvändiga förändringar beror i stor utsträckning på:

  • Hur många ändringar i API: n påverkar den aktuella funktionaliteten.
    Vid hur många punkter pluginförfattarna har använt delar av API: n som de skulle ändra.
  • Vad kommer de viktigaste ändringarna för 3.0?

Det finns fyra nyckelområden du vill ändra i 3.0:

 

Qt4 uppdatering till QT5: Detta är den grundläggande uppsättningen bibliotek där QGIS är byggt på den översta nivån, vi talar om plattformens CORE-funktionella nivå. QT tillhandahåller också bibliotek för att utföra minneshantering, anslutningsoperationer och grafikhantering. Qt4 (som QGIS för närvarande baseras på) utvecklas för närvarande inte av de ansvariga för Qt-biblioteket och kan ha problem med funktionalitet med vissa plattformar (till exempel OS X) och till och med underlätta hanteringen av binära versioner (till exempel Debian Testing och den kommande Debian "Stretch" -versionen). Processen med att ta QGIS till QT5 har redan ett viktigt framsteg (främst vad Matthias Kuhn har gjort) som tillsammans med Marco Bernasocchi röker på Android «QField» baserat helt på QT5. Det finns dock vissa begränsningar i lanseringen av den nya QT5 på grund av dess inverkan på QGIS - särskilt med webbläsarwidgets (används främst i Composer och även andra platser i QGIS).

Uppdatera PyQt4 till PyQt5: Det här är de relativa ändringarna i Pythonspråk för Qt, på vilket QGIS Python API är baserat. Uppstår ändrar QT5 C ++ bibliotek, förväntas också att överföra till PyQt5 Python-bibliotek, så att de kan dra nytta av fördelarna med den nya API i Python QT5.
2.7: Uppdatering av Python 3 till Python För närvarande går allt på Python 2.7. Python 3 är den senaste versionen av python och rekommenderas av de som leder det projektet. Python 2 är lite inkompatibel med Python 3 (nästan proportionell mot inkompatibiliteten mellan QGIS 2 och Qgis 3). Många utvecklare har gjort python Python 3 till stor del bakåtkompatibel med Python 2, men bakåtkompatibiliteten är inte så bra.
Förbättringen av QGIS API själv: Ett av problemen med vilket det upprätthåller API-kompatibilitet mellan versioner är att du måste leva med dina designalternativ på lång sikt. I QGIS görs allt för att inte bryta API: et inom en serie mindre utgåvor. Att släppa en version av QGIS för 3.0 med ett API som inte är aktuellt med strömmen ger en möjlighet att "städa huset" genom att fixa de saker i API som vi är med om att det är oenighet. Du kan se en preliminär lista över Föreslagna ändringar för 3.0 API.

Så här stödjer du ändringen av 3.0 API

Som redan nämnts kommer version 3.0 att brytas med QGIS version 2.x och det finns en chans att många plugins, befintliga applikationer och annan kod som är baserad på det aktuella API kommer att brytas. Så vad kan man göra för att mildra förändringarna? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias och andra topputvecklare har letat efter sätt att mildra antalet API-pausförändringar samtidigt som de fortsätter att utveckla QGIS-kodbasen baserat på nästa generation bibliotek och en egen intern API. Under vårt sista möte i QGIS Project Steering Committee var det geofumed genom olika möjligheter. Följande tabell sammanfattar vad Matthias Kuhn nådigt sammanfattade och som vi delvis har försökt att translitterera i den här artikeln enligt vad postat på sin blogg:


QGIS 2.14 LTR
QGIS 2.16 ??? QGIS 3.0
Utgivningsdatum Slutet av februari 4 månader senare 2.14 Cykel 8 månader?
anteckningar Uppdatera Python-koden för kärnan QGIS för att vara Python 3-kompatibel och PyQt5-kompatibel (delvis implementering för nyckelfunktioner, t.ex. konsol, python-kärnproppar etc.)
Qt4 Si

Utfärdad i Debian Stretch (förfallna på ett år)

(webbkit borttagen)

Ja Nej
Qt5 Nej

Missar QWebView - Ny ersättning inte på alla plattformar. Missar också QPainter Engine.

Si Si
PyQt4 Si Si Nej
PyQt5 Nej Si Si
python 2 Si Si Nej
python 3 Nej Si Si
API-rengöring Nej Nej Si
omslag
PyQt5 -> PyQt4
Ger ~ 90% bakåtkompatibilitet
Nej Si Si
Mainstream Binär Qt4 Baserat Qt4 Baserat Qt5 Baserat
Prioritering av finansieringen Python wrappers

Det finns två viktiga saker att komma ihåg om Matias förslag:

I första fasenArbetet sker i serien för att slutföra 2.x stöd QT5, PyQt5 använder Python 3.0, stödja Qt4, PyQt4 och Python 2.7. Detta innebär att alla ändringar som gjorts i den första fasen skulle vara kompatibla med tidigare 2.x-versioner. Python funktioner kommer att införlivas kommer att införas så att den gamla API PyQt4 kan fortfarande användas speciellt när sammanställs mot QT5, PyQt5, Python 3.0. När du använder QGIS kompilerat mot Qt4, PyQt4 och Python 2.7 skulle det inte finnas någon nedbrytningskompatibilitet.
I andra fasenDet skulle fungera att producera qgis 3.0, införa den nya API, helt ta bort Python 2.7, inklusive stöd för Qt4 och PyQt4. Nya funktioner i Python in den första fasen kommer att bibehållas, med hänsyn till alla Python-kod och utveckling för 2.x versioner av qgis fortsätta att arbeta på 3.x versionerna av qgis. I denna fas förväntas du också införa ändringar i QGIS API som kan bryta några plugins. För att ta itu med detta kommer vi att tillhandahålla en migreringsguide för att försöka underlätta migreringsprocessen från 2.x QGIS-versioner till 3.x QGIS-versioner.

Caveat emptor

Det finns ett par knep som bör införas för att säkerställa att migration till QGIS 3.0 låter mindre smärtsamt.

  • 1. SDet bör noteras att även om det tillvägagångssätt som anges ovan försöker minimera mängden arbete med python-skript i plugins kommer detta inte nödvändigtvis att vara 100%. Det kommer sannolikt att vara fall där koden måste justeras och i alla fall åtminstone kommer den sannolikt att behöva revideras för att säkerställa att den fortsätter att fungera korrekt.
    2. Det finns ingen formellt etablerad ekonomisk resurs för att betala utvecklare som frivilligt investerar sin tid för denna migrationsprocess. På grund av detta blir det mycket svårt att ge exakta tidsramar för hur lång tid varje del av processen tar. Denna osäkerhet måste beaktas vid planeringen. Naturligtvis är donationer välkomna för att få detta att hända.
    3. Det kan finnas utvecklare och institutioner där ute som finansierar nya funktioner för QGIS 2.x-serien och detta kan påverka ditt arbete. Det är nödvändigt att inkludera en viss fördelning i planerna och budgetarna för dessa projekt för att möta migrationen till QGIS 3.x-plattformen.
    4. Om QGIS-teamet arbetar med en "total förändring" kommer det att vara relativt kort tid under vilken QGIS kommer att vara instabil och ständigt förändras på grund av de pågående uppdateringarna av QGIS 3.0.
    4. Om du utvecklas på ett "evolutionärt" sätt riskerar du att 3.0-utvecklingen kan ta längre tid om du inte har en lojal grupp utvecklare som arbetar med den och gör dig redo att migrera.

    Förslagen

Mot bakgrund av all ovanstående information föreslås en av de två handlingslinjerna:

1-förslag:

Släpp en interimversion 2.16 och börja arbeta med version 3.0 som en prioritet, med ett utvecklingsfönster på 8 månader. Ändringar som görs i version 2.16 försöker vara kompatibla med version 3.0 (se python3 / pytq5).

2-förslag:

Utfall gång 3.0 med en mer förlängd duration fönster QT5, Python 3.0 och PyQt5 och be utvecklare att göra sitt arbete i 3.0. Fortsätt med 2.x-versioner med jämna mellanrum tills 3.0 är klar.

Alternativa förslag

Har du ett alternativt förslag? QGIS är intresserad av att veta om möjliga alternativ. Om du vill skicka in ett förslag, vänligen skicka till tim@qgis.org med ämnet "QGIS 3.0-förslag".

Bör följa QGIS blogg, där denna publikation kom ut.

Lämna ett svar

Din e-postadress kommer inte att publiceras.

Den här sidan använder Akismet för att minska spam. Läs om hur din kommentardata behandlas.