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?

Vanligtvis ä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 av bibliotek som QGIS är byggd på toppnivå, 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 är baserad på) utvecklas för närvarande inte av Qt-bibliotekets underhållare och kan ha funktionsproblem med vissa plattformar (t.ex. OS X) och till och med göra det lättare att hantera binära versioner (t.ex. Debian Testing och nästa Debian-version "Sträcka"). Processen att föra 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" helt baserat på QT5. Det finns dock vissa begränsningar för att få den nya QT5 igång på grund av dess inverkan på QGIS – särskilt med webbläsarwidgets (används främst i Composer och även några 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 att upprätthålla API-kompatibilitet mellan versioner är att du måste leva med dina designval under lång tid. Alla ansträngningar görs i QGIS för att inte bryta API:et i en serie mindre utgåvor. Att släppa en QGIS-version för 3.0 med ett API som för närvarande inte stöds kommer att ge oss en möjlighet att "städa huset" genom att fixa saker i API:t som vi inte är kompatibla med. 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:

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 finnas en relativt kort tid under vilken QGIS kommer att vara instabil och ständigt förändras på grund av pågående uppdateringar av QGIS 3.0.
  4. Om du utvecklar 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 det och gör det redo att portas.

  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 Proposal".

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