QGIS 3.0 - Hvordan, når og hva; hjelp

Mange av oss spør:

Når vil QGIS 3.0 bli utgitt?

I fjor (2015) begynte prosjektgruppen å undersøke når og hvordan QGIS 3.0 skulle bli utgitt. De lovet, ifølge et innlegg fra Anita Graser, at de klart ville formidle til brukerne og utviklerne av sine planer før de startet QGIS 3.0. Nylig har de forsøkt å avsløre noen av hensynene til lansering av QGIS 3.0, og på slutten av innlegget er det en mulighet for oss å presentere våre ideer.

Hvorfor 3.0?

QGis_LogoNormalt er en stor versjon reservert for tider når en stor endring er gjort i APIen til programvaren. Denne pause er ikke en triviell beslutning for QGIS-prosjektet, siden vi er hundrevis av tusenvis av brukere som er avhengige av QGIS, både til eget bruk og for service til tredjepart.

Av og bryte API er nødvendig for å imøtekomme oppdatere arkitektur med forbedrede metoder, nye biblioteker og rettelser til vedtak gjort i fortiden.

Hva er konsekvensene av å bryte API?

En grunn til at dette brudd på API i QGIS 3.0 er at det vil ha en stor innvirkning, noe som kunne bryte hundrevis av utviklede plugins som ikke lenger vil være kompatibel med den nye API og forfatterne av disse har å gjøre en gjennomgang av dens utvikling for å sikre kompatibilitet med den nye API.

Omfanget av de endringene som trengs, avhenger i stor grad på:

  • Mange API endringene påvirker dagens funksjonalitet.
    Hvor mange poeng plugins forfattere har brukt deler av API som ville endre.
  • Hva er de viktigste endringene i 3.0?

Det er fire viktige områder som er ute etter endring på 3.0:

Qt4 til QT5 oppdatering: Dette er det grunnleggende settet med biblioteker der QGIS er bygget på toppnivå, vi snakker om plattformens CORE-funksjonelle nivå. QT gir også biblioteker mulighet til å utføre momestyring, tilkoblingsoperasjoner og grafikkbehandling. Den Qt4 (der QGIS er for tiden basert) ikke nå utviklet av de ansvarlige for Qt-biblioteket, og kan ha problemer i form av funksjonalitet med noen plattformer (som OS X) og selv forenkle forvaltningen av binære versjoner (for eksempel Debian Testing og den neste versjonen av Debian «Stretch»). Prosessen med å bringe QGIS å QT5 har allerede et gjennombrudd (hovedsakelig det som gjorde Matthias Kuhn) sammen med Marco Bernasocchi røyk på Android "QField" basert utelukkende på QT5. Det er imidlertid noen begrensninger for å lansere den nye QT5 for dens innvirkning på QGIS - spesielt med widgets nettlesere (brukes hovedsakelig i Komponist og noen andre steder i QGIS).

PyQt4 til PyQt5 oppdatering: Disse endringene er knyttet til Python språket for Qt i QGIS Python API er basert på. Oppstår endre QT5 C ++ bibliotek, forventes også å overføre til PyQt5 python-biblioteket, slik at de kan dra nytte av fordelene med den nye API i Python QT5.
Oppdatering Python Python 2.7 3 til: For tiden går alt på Python 2.7. Python 3 er den nyeste versjonen av python og anbefales av de som leder prosjektet. Python 2 er litt inkompatibel med Python 3 (i en grad nesten proporsjonal med inkompatibiliteten mellom QGIS 2 og Qgis 3). Mange utviklere har gjort Python Python 3 stort sett kompatibel med tidligere versjoner av Python 2, men omvendt kompatibilitet er ikke så bra.
Forbedre QGIS egen API: Et av problemene som opprettholder API-kompatibilitet mellom versjoner er at du må leve med designalternativer for en langsiktig periode. I QGIS er det gjort alt for å ikke bryte API i en serie med mindre utgivelser. Å frigjøre en QGIS-versjon for 3.0 med en API som ikke er kompatibel med gjeldende, vil gi en mulighet til å "rense huset" ved å fikse ting i APIen som vi er med som det er uoverensstemmelse. Du kan se en foreløpig liste over 3.0 forslag til endringer i API.

Hvordan støtte endre 3.0 API

Som allerede nevnt, er versjonen 3.0 en pause med QGIS versjon 2.x føre, og det er en mulighet for at mange plugg, eksisterende applikasjoner og andre koder er basert på gjeldende API brekkasje. Så hva kan gjøres for å redusere endringene? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias og andre store utviklere har vært på jakt etter måter å redusere antall API bryte endringer samtidig fremme basen kode QGIS være basert på neste generasjon av biblioteker og sine egne interne API. Under vårt siste møte QGIS prosjektets styringskomité ble geofumó gjennom ulike muligheter. Tabellen nedenfor oppsummerer hva Matthias Kuhn summert forsiktig og dels har forsøkt å translittererer i denne artikkelen i henhold til hva De publisert på bloggen sin:


QGIS 2.14 LTR
QGIS 2.16 ??? QGIS 3.0
Utgivelsesdato Slutten av februar 4 2.14 måneder ¿Cycle 8 måneder?
notater Oppdatering av kjerne QGIS python kode Python 3 for å være kompatibel og støtter PyQt5 (delvis gjennomføring for funksjonaliteter f.eks konsoll, python kjerne plugg etc.)
Qt4 Si

Foreldet i Debian Stretch (på grunn i et år)

(-webkit fjernet)

Ja Nei
Qt5 Nei

Misses QWebView - ny erstatning ikke på alle plattformer. Savner også QPainter Engine.

Si Si
PyQt4 Si Si Nei
PyQt5 Nei Si Si
Python 2 Si Si Nei
Python 3 Nei Si Si
opprydding API Nei Nei Si
pakkere
PyQt5 -> PyQt4
~ 90% gir bakoverkompatibilitet
Nei Si Si
mainstream Binary basert Qt4 basert Qt4 basert Qt5
finansiering prioritet python wrappers

Det er to viktige ting å merke seg om forslaget Matthias:

I den første fasenArbeidet er gjort i serie for å fullføre 2.x støtte QT5, PyQt5 Python 3.0, som støtter Qt4, PyQt4 og Python 2.7. Dette innebærer at alle endringer som er gjort i den første fasen vil være kompatibel med tidligere versjoner 2.x. Python funksjoner vil bli innarbeidet vil bli innført, slik at den gamle API PyQt4 fortsatt kan benyttes spesielt når kompilert mot QT5, PyQt5, Python 3.0. Ved å bruke QGIS kompilert mot Qt4, PyQt4 og Python 2.7 ville ikke bryte kompatibilitet.
I den andre fasenDet ville fungere for å produsere QGIS 3.0, innføring av den nye API fjerne helt Python 2.7, inkludert støtte for Qt4 og PyQt4. Nye funksjoner i python som kommer inn i første fase vil bli opprettholdt, tar hensyn til alle python kode og utviklingen for 2.x versjoner av QGIS fortsette å arbeide på 3.x versjoner av QGIS. Denne fasen er også forventet å innføre endringer i QGIS API som kan brekke noen programtillegg. For å løse dette vil gi veiledning aa migrasjon for å prøve å legge til rette for migrasjon av versjonene 2.x QGIS 3.x QGIS versjoner.

forbeholdet emptor

Det finnes noen triks for å bli bedt om å sikre at overgangen til QGIS 3.0 høres mindre smertefull.

  • 1. Se bør bemerkes at mens fokus er satt opp for å minimere mengden av arbeid på python skripting plugins, vil dette ikke nødvendigvis en 100%. Det vil mest sannsynlig tilfeller der koden må justeres og i alle tilfeller minst, har du sannsynligvis må revideres for å sikre at den fortsetter å fungere som den skal.
    2. Det er ingen formelt etablert økonomiske ressurser til å betale utviklere som frivillig investere sin tid for denne migrasjonsprosessen. På grunn av dette, vil det være svært vanskelig å gi eksakte tidspunktet hvor lang tid det vil ta hver del av prosessen. Det bør ta hensyn til denne usikkerheten i planleggingen. Selvfølgelig donasjoner velkommen åpner for å gjøre dette skje.
    3. Det kan være utviklere og institusjoner der ute som finansierer nye funksjoner for 2.x QGIS serien, og dette kan påvirke deres arbeid. Inkluderes i planer og budsjetter for disse prosjektene, til en viss fordeling ta overgangen til 3.x QGIS plattform.
    4. Hvis QGIS-teamet jobber med en "total endring", vil det være en relativt kort tid der QGIS vil være ustabil og stadig endres på grunn av løpende oppdateringer til QGIS 3.0.
    4. Dersom utviklet så 'evolusjonær'', du kjører risikoen for å utvikle 3.0 kan ta lengre tid med mindre du har en lojal gruppe utviklere som jobber med dette, og gjør deg klar til å migrere.

    Forslag

I lys av alle de ovennevnte opplysninger, er en av to kurs av handlingen foreslått:

1 forslag:

2.16 slipper et utkast versjon og deretter begynne å jobbe på 3.0 versjonen som en prioritet, med et vindu utviklings 8 måneder. Endringer som gjøres i versjon 2.16 søke å være kompatibel med 3.0 versjon (se python3 / pytq5).

2 forslag:

Lonsjering gang 3.0 med en mer utvidet varighet vindu på QT5, Python 3.0 og PyQt5 og be utviklere å gjøre sitt arbeid i 3.0. Fortsett med 2.x versjoner med vanlig frekvens inntil 3.0 er klar.

alternative forslag

Har du et alternativt forslag? En QGIS bryr seg noe om mulige alternativer. Hvis du ønsker å sende inn et forslag, send tim@qgis.org med emnet "QGIS 3.0 Proposal".

Bør følge QGIS bloggen: Hvor kom denne publikasjonen.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.

Dette nettstedet bruker Akismet for å redusere spam. Lær hvordan kommentardataene dine behandles.