QGIS 3.0 - Hoe, wanneer en wat; het impliceert

Velen vragen onszelf:

Wanneer wordt QGIS 3.0 vrijgegeven?

Vorig jaar (2015) begon het projectteam te onderzoeken wanneer en hoe QGIS 3.0 zou worden vrijgegeven. Ze beloofden, volgens een bericht van Anita Graser, dat ze hun plannen duidelijk aan gebruikers en ontwikkelaars zouden overbrengen voordat QGIS 3.0 werd gelanceerd. Ze hebben onlangs geprobeerd enkele overwegingen voor een uitgave van QGIS 3.0 bloot te leggen en aan het einde van de post is er een gelegenheid voor ons om onze ideeën te presenteren.

Waarom 3.0?

Meestal is een hoofdversie gereserveerd voor momenten waarop een grote wijziging wordt aangebracht in de API van uw software. Deze onderbreking is geen triviale beslissing voor het QGIS-project, aangezien we honderdduizenden gebruikers zijn die afhankelijk zijn van QGIS, zowel voor ons eigen gebruik als voor diensten die aan derden worden geleverd.

Af en toe is de API nodig om de upgrade van de architectuur te verbeteren met verbeterde benaderingen, nieuwe bibliotheken en correcties op beslissingen in het verleden.

Wat zijn de gevolgen van het breken van de API?

Een van de redenen waarom deze schending van de API in QGIS 3.0 is dat het een grote impact, waarbij honderden ontwikkelde plugins die niet meer compatibel met de nieuwe API zou zijn en de auteurs van deze zou kunnen breken hebben te doen zal hebben een beoordeling van hun ontwikkelingen om compatibiliteit met de nieuwe API te garanderen.

De omvang van de noodzakelijke veranderingen hangt in grote mate af van:

• Hoeveel wijzigingen in de API beïnvloeden de huidige functionaliteit.
  Op hoeveel punten hebben de plugin-auteurs onderdelen van de API gebruikt die ze zouden veranderen.

• Wat zijn de belangrijkste veranderingen voor 3.0?

Er zijn vier sleutelgebieden die u in 3.0 wilt veranderen:

Qt4 update naar QT5: Dit is de basisset van bibliotheken waarop QGIS is gebouwd op het hoogste niveau, we spreken van het CORE-functionele niveau van het platform. QT biedt ook bibliotheken voor het uitvoeren van geheugenbeheer, verbindingsbewerkingen en grafisch beheer. Qt4 (waar QGIS momenteel op is gebaseerd) wordt momenteel niet ontwikkeld door de Qt-bibliotheekbeheerders en kan functionaliteitsproblemen hebben met sommige platforms (bijv. OS X) en maakt het zelfs gemakkelijker om binaire versies te beheren (bijv. Debian Testing en de volgende Debian-release "Rekken"). Het proces om QGIS naar QT5 te brengen heeft al een belangrijke vooruitgang (voornamelijk wat Matthias Kuhn heeft gedaan) dat samen met Marco Bernasocchi rookt op Android "QField", volledig gebaseerd op QT5. Er zijn echter enkele beperkingen om de nieuwe QT5 in gebruik te nemen vanwege de impact op QGIS – in het bijzonder met webbrowserwidgets (voornamelijk gebruikt in Composer en ook op een paar andere plaatsen in QGIS).

Update PyQt4 naar PyQt5: Dit zijn de relatieve wijzigingen in de Python-taal voor Qt waarop de QGIS Python-API is gebaseerd. Ontstaat verander de QT5 C ++ library, zal naar verwachting ook over te dragen aan PyQt5 python bibliotheek, zodat ze kunnen profiteren van de voordelen van de nieuwe API in Python QT5.
2.7: Python 3 bij Python bijwerken Momenteel draait alles op Python 2.7. Python 3 is de nieuwste versie van python en wordt aanbevolen door degenen die dat project leiden. Python 2 is enigszins incompatibel met Python 3 (bijna evenredig met de incompatibiliteit tussen QGIS 2 en Qgis 3). Veel ontwikkelaars hebben Python Python 3 grotendeels achterwaarts compatibel gemaakt met Python 2, maar de achterwaartse compatibiliteit is niet zo geweldig.
Verbetering van de QGIS API zelf: Een van de problemen met het onderhouden van API-compatibiliteit tussen versies is dat je voor de lange termijn met je ontwerpkeuzes moet leven. Elke poging wordt gedaan in QGIS om de API niet te breken in een reeks van kleine releases. Het vrijgeven van een versie van QGIS voor 3.0 met een API die momenteel niet wordt ondersteund, geeft ons de mogelijkheid om "het huis schoon te maken" door dingen in de API te repareren waar we niet mee in overeenstemming zijn. U kunt een voorlopige lijst zien van: wijzigingen voorgesteld voor de 3.0 API.

Hoe u de 3.0 API kunt wijzigen

Zoals reeds vermeld, zal versie 3.0 breken met QGIS versie 2.x en is er een kans dat veel plug-ins, bestaande applicaties en andere code die gebaseerd zijn op de huidige API zullen breken. Dus wat kan er worden gedaan om de veranderingen te beperken? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias en andere topontwikkelaars hebben gezocht naar manieren om het aantal wijzigingen in API-onderbrekingen te beperken, terwijl ze doorgaan met het ontwikkelen van de codebase van QGIS, gebaseerd op de volgende generatie bibliotheken en zijn eigen interne API. Tijdens onze laatste bijeenkomst van de QGIS Projectstuurcommissie werd het geofumeerd door middel van verschillende mogelijkheden. De volgende tabel vat samen wat Matthias Kuhn gracieus samenvatte en dat we in dit artikel gedeeltelijk hebben geprobeerd te translitereren volgens wat geplaatst op je blog:

Er zijn twee belangrijke dingen om in gedachten te houden over het voorstel van Matias:

In de eerste faseHet werk wordt gedaan in de serie 2.x steun QT5 voltooien PyQt5 met Python 3.0 ondersteunen Qt4, PyQt4 en Python 2.7. Dit impliceert dat alle veranderingen die in de eerste fase zijn gemaakt, verenigbaar zijn met eerdere 2.x versies. Python functies zullen worden opgenomen zal worden ingevoerd zodat de oude API PyQt4 nog vooral kan worden gebruikt wanneer gecompileerd QT5, PyQt5, Python 3.0. Bij gebruik van QGIS gecompileerd tegen Qt4, PyQt4 en Python 2.7 zou er geen pauze compatibiliteit zijn.
In de tweede fase, zou je werken om QGIS 3.0 te produceren, de nieuwe API introduceren, zal Python 2.7 volledig worden verwijderd, inclusief ondersteuning voor Qt4 en PyQt4. Nieuwe functies in python het invoeren van de eerste fase zal worden gehandhaafd, rekening houdend met alle van de python code en ontwikkelingen voor 2.x versies van QGIS blijven werken aan de 3.x versies van QGIS. In deze fase wordt ook verwacht dat wijzigingen aanbrengen in de QGIS API die sommige plugins kan breken. Om dit aan te pakken, zullen we een migreringsgids verschaffen om het migratieproces te verbeteren van 2.x QGIS-versies naar 3.x QGIS-versies.

Caveat emptor

Er zijn een paar trucs die moeten worden opgesteld om ervoor te zorgen dat migratie naar QGIS 3.0 klinkt minder pijnlijk.

• 1. SOpgemerkt moet worden dat hoewel de hierboven uiteengezette aanpak probeert de hoeveelheid werk aan python-scripting in plug-ins te minimaliseren, dit niet noodzakelijk 100% zal zijn. Er zullen hoogstwaarschijnlijk gevallen zijn waarin de code moet worden aangepast en in alle gevallen zal deze waarschijnlijk moeten worden herzien om ervoor te zorgen dat deze correct blijft functioneren.
  2. Er is geen formeel vastgestelde financiële bron om ontwikkelaars te betalen die vrijwillig hun tijd in dit migratieproces investeren. Hierdoor zal het erg moeilijk zijn om exacte tijdschema's te geven voor hoe lang elk onderdeel van het proces zal duren. Bij de planning moet met deze onzekerheid rekening worden gehouden. Donaties zijn natuurlijk welkom om dit mogelijk te maken.
  3. Er kunnen ontwikkelaars en instellingen zijn die nieuwe functies voor de QGIS 2.x-serie financieren en dit kan uw werk beïnvloeden. Het is noodzakelijk om in de plannen en budgetten van deze projecten een bepaalde toewijzing op te nemen om de migratie naar het QGIS 3.x-platform het hoofd te bieden.
  4. Als het team van QGIS werkt aan een "totale verandering", zal er een relatief korte tijd zijn waarin QGIS onstabiel zal zijn en constant zal veranderen als gevolg van voortdurende updates voor QGIS 3.0.
  4. Als je op een 'evolutionaire' manier ontwikkelt, loop je het risico dat de ontwikkeling van 3.0 langer duurt, tenzij je een loyale groep ontwikkelaars hebt die eraan werkt en het klaar maakt om te porten.

  Voorstellen

In het licht van alle bovenstaande informatie wordt een van de twee actielijnen voorgesteld:

1 Voorstel:

Geef een tussentijdse versie 2.16 uit en begin dan met prioriteit aan versie 3.0 te werken, met een ontwikkelvenster van 8 maanden. Wijzigingen aangebracht in versie 2.16 zullen proberen compatibel te zijn met versie 3.0 (zie python3 / pytq5).

2 Voorstel:

Start 3.0 tegelijkertijd met een langere duur venster op QT5, Python 3.0 en PyQt5, en vraag ontwikkelaars om hun werk op 3.0 te doen. Ga door met 2.x versies met regelmatige tussenpozen tot 3.0 klaar is.

Alternatieve voorstellen

Heeft u een alternatief voorstel? QGIS is geïnteresseerd in het kennen van mogelijke alternatieven. Als u een voorstel wilt indienen, stuur dan naar tim@qgis.org met het onderwerp "Voorstel voor QGIS 3.0".

Moeten volgen de QGIS blog, waar deze publicatie uitkomt.