QGIS 3.0 - Hur, när och vad; medel

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 klart skulle vidarebefordra användarna och utvecklarna av sina planer innan de startade QGIS 3.0. Nyligen har de försökt att avslöja några av övervägandena för en lansering av QGIS 3.0 och i slutet av posten finns det en möjlighet för oss att presentera våra idéer.

Varför 3.0?

QGis_LogoNormalt är en huvudversion reserverad för tider då en stor förändring görs till API för din programvara. Denna paus är inte en trivial beslut för qgis projektet som 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: Det här är den grundläggande uppsättningen bibliotek där QGIS är byggt på översta nivå, vi talar om plattformens CORE-funktionella nivå. QT ger också bibliotek att utföra momory management, connectivity operationer och grafikhantering. Den Qt4 (där qgis närvarande baserad) inte nu utvecklas av de ansvariga för Qt biblioteket och kan få problem när det gäller funktionalitet med vissa plattformar (t.ex. OS X) och även underlätta hanteringen av binära versioner (till exempel Debian Testing och nästa version av Debian «Stretch»). Processen att föra qgis till QT5 har redan ett genombrott (främst vad gjorde Matthias Kuhn) tillsammans med Marco Bernasocchi rök på Android "QField" helt baserad på QT5. Det finns dock vissa begränsningar för att lansera den nya QT5 för dess inverkan på qgis - särskilt med widgets webbläsare (används främst i Composer och vissa 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 dem som leder projektet. Python 2 är något inkompatibel med Python 3 (i en omfattning som är nästan proportionell mot inkompatibiliteten mellan QGIS 2 och Qgis 3). Många utvecklare har gjort Python Python 3 till stor del kompatibel med tidigare versioner av Python 2, men omvänd kompatibilitet är inte lika 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 designalternativ på lång sikt. I QGIS görs allt för att inte bryta API: n inom en serie mindre utgåvor. Att frigöra en QGIS-version för 3.0 med ett API som inte är kompatibelt med det aktuella kommer att ge möjlighet att "städa huset" genom att fixa saker i det API som vi är med vilka det finns överensstämmelse. 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, den version 3.0 en brytning med qgis version 2.x orsak och det finns möjlighet att många plugins, existerande applikationer och andra koder är baserade på den aktuella API brott. Så vad kan man göra för att mildra förändringarna? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias och andra stora utvecklare har letat efter sätt att minska antalet API bryta förändringar samtidigt framåt baskoden qgis baseras på nästa generations bibliotek och sin egen interna API. Under vårt senaste möte i styrkommittén för QGIS-projektet var geofumó genom flera möjligheter. Följande tabell sammanfattar vad Matthias Kuhn vänligt sammanfattade och som vi delvis har försökt översätta i denna artikel 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 medan den metod som anges ovan är avsedd att minimera mängden arbete i python-skript i plugins, kommer detta inte nödvändigtvis att vara i en 100%. Det kommer sannolikt att finnas fall där koden måste anpassas och i alla fall åtminstone kommer det troligen att behöva ses över för att säkerställa att det fortsätter att fungera ordentligt.
    2. Det finns ingen formellt etablerad ekonomisk resurs för att betala utvecklare som frivilligt investerar sin tid i denna migrationsprocess. På grund av detta blir det mycket svårt att ge exakta tidslinjer om hur lång tid varje del av processen tar. Denna osäkerhet måste beaktas vid planeringen. Givetvis är donationer välkomna för att göra det möjligt att hända detta.
    3. Det kan finnas utvecklare och institutioner där ute som finansierar nya funktioner för 2.x QGIS-serien och detta kan påverka sitt arbete. I planerna och budgetarna för dessa projekt måste en del fördelning för att hantera migrationen till XGUMX.x-plattformen för QGIS inkluderas.
    4. Om QGIS-teamet arbetar med en "total förändring" kommer det att bli en relativt kort tid under vilken QGIS blir instabil och ständigt förändras på grund av pågående uppdateringar av QGIS 3.0.
    4. Om det utvecklas på en "evolutionär" sätt finns risk för att 3.0-utveckling kan ta längre tid om det inte finns en lojal grupp utvecklare som arbetar med den och gör den 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 preliminär 2.16-version och börja sedan arbeta med 3.0-versionen som en prioritet, med ett utvecklingsfönster på 8 månader. Ändringar som gjorts i 2.16-versionen ser ut att vara kompatibla med 3.0-versionen (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 känna till möjliga alternativ. Om du vill lämna ett förslag, skicka det tim@qgis.org med ämnet "QGIS 3.0-förslag".

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

Lämna en kommentar

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.