QGIS 3.0 - Jak, kiedy i co; to oznacza

Wielu pyta siebie:

Kiedy QGIS 3.0 zostanie wydany?

W ubiegłym roku (2015) zespół projektowy zaczął badać, kiedy i jak QGIS 3.0 miał zostać wydany. Obiecali, według stanowiska z Anita Graser, że zamierzają jasno przekazać swoje plany użytkownikom i programistom przed uruchomieniem QGIS 3.0. Niedawno próbowali ujawnić niektóre kwestie związane z wydaniem QGIS 3.0, a na końcu posta mamy okazję przedstawić nasze pomysły.

Dlaczego 3.0?

Zazwyczaj wersja główna jest zarezerwowana na czasy, gdy w interfejsie API oprogramowania wprowadzana jest duża zmiana. Ta przerwa nie jest trywialną decyzją dla projektu QGIS, ponieważ jesteśmy setkami tysięcy użytkowników, którzy polegają na QGIS, zarówno na własny użytek, jak i usługi świadczone na rzecz osób trzecich.

Czasami łamanie interfejsu API jest konieczne, aby pomieścić aktualizację architektury z ulepszonymi podejściami, nowymi bibliotekami i korektami podejmowanymi w przeszłości.

Jakie są konsekwencje zerwania API?

Jednym z powodów, dlaczego to naruszenie API w QGIS 3.0 jest to, że będzie to miało duży wpływ, który może przełamać setki wtyczek rozwiniętych, które nie są już zgodne z nowym API i autorów z nich zrobić przegląd ich sytuacji w celu zapewnienia zgodności z nowym interfejsem API.

Zakres niezbędnych zmian zależy w dużym stopniu od:

• Ile zmian w interfejsie API wpływa na bieżącą funkcjonalność.
  W ilu punktach autorzy pluginów korzystali z części interfejsu API, które zmieniłyby się.

• Jakie będą główne zmiany w 3.0?

Istnieją cztery główne obszary, które chcesz zmienić w 3.0:

Aktualizacja Qt4 do QT5: Jest to podstawowy zestaw bibliotek, które QGIS jest budowany na najwyższym poziomie, mówimy o poziomie funkcjonalnym CORE platformy. QT zapewnia również biblioteki do zarządzania pamięcią, operacji łączności i zarządzania grafiką. Qt4 (na którym obecnie opiera się QGIS) nie jest obecnie rozwijany przez opiekunów biblioteki Qt i może mieć problemy z funkcjonalnością na niektórych platformach (np. OS X) a nawet ułatwić zarządzanie wersjami binarnymi (np. Debian Testing i następne wydanie Debiana "Rozciągać"). Proces przenoszenia QGIS do QT5 ma już ważny postęp (głównie to, co zrobił Matthias Kuhn), który wraz z Marco Bernasocchi pali na Androidzie „QField” opartym całkowicie na QT5. Istnieją jednak pewne ograniczenia w uruchomieniu nowego QT5 ze względu na jego wpływ na QGIS – w szczególności z widżetami przeglądarki internetowej (używanymi głównie w Composerze, a także w kilku innych miejscach w QGIS).

Zaktualizuj PyQt4 do PyQt5: Są to względne zmiany języka Pythona dla Qt, na którym opiera się API QGIS Python. Powstaje zmienić bibliotekę QT5 C ++ oczekuje się również przenieść do PyQt5 Pythona biblioteki tak, że mogą skorzystać z zalet nowego interfejsu API w Pythonie QT5.
2.7: Aktualizowanie Pythona 3 do Pythona Obecnie wszystko działa na Pythonie 2.7. Python 3 to najnowsza wersja Pythona i jest zalecana przez kierowników tego projektu. Python 2 jest nieco niekompatybilny z Pythonem 3 (prawie proporcjonalnie do niekompatybilności między QGIS 2 i Qgis 3). Wielu programistów sprawiło, że Python Python 3 jest w dużej mierze kompatybilny wstecz z Pythonem 2, ale kompatybilność wsteczna nie jest tak dobra.
Poprawa samego interfejsu QGIS API: Jednym z problemów związanych z utrzymywaniem zgodności API między wersjami jest to, że musisz długo żyć ze swoimi wyborami projektowymi. W QGIS dokłada się wszelkich starań, aby nie zepsuć API w serii mniejszych wydań. Wydanie wersji QGIS dla 3.0 z API, które nie jest obecnie obsługiwane, da nam możliwość „posprzątania domu” poprzez naprawienie rzeczy w API, z którymi nie jesteśmy w zgodzie. Możesz zobaczyć tymczasową listę proponowane zmiany w interfejsie API 3.0.

Jak wspierać zmianę interfejsu API 3.0

Jak już wspomniano, wersja 3.0 zepsuje się z wersją QGIS 2.x i istnieje szansa, że ​​wiele wtyczek, istniejących aplikacji i innego kodu opartego na obecnym API ulegnie awarii. Co więc można zrobić, aby złagodzić zmiany? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias i inni czołowi programiści szukali sposobów na złagodzenie liczby zmian w API, jednocześnie kontynuując ulepszanie bazy kodu QGIS opartej na następnej generacji bibliotek i własnym wewnętrznym API. Podczas naszego ostatniego spotkania Komitetu Sterującego Projektu QGIS przeanalizowaliśmy różne możliwości. Poniższa tabela podsumowuje to, co Matthias Kuhn łaskawie podsumował i że częściowo próbowaliśmy transliterować w tym artykule zgodnie z tym, co opublikowane na blogu:

Istnieją dwie ważne rzeczy, o których warto pamiętać o propozycji Matias:

W pierwszej faziePraca jest wykonywana w serii do ukończenia 2.x support QT5, PyQt5 użyciu Pythona 3.0, wspieranie Qt4, PyQt4 i Python 2.7. Oznacza to, że wszystkie zmiany dokonane w pierwszej fazie byłyby zgodne z wcześniejszymi wersjami 2.x. Python funkcje zostaną włączone zostaną wprowadzone tak, że stary API PyQt4 mogą być nadal używane zwłaszcza gdy kompilowany przeciwko QT5, PyQt5, Python 3.0. Za pomocą QGIS skompilowane przeciwko Qt4, PyQt4 i Python 2.7 nie złamać kompatybilności.
W drugiej faziebędzie pracować produkować QGIS 3.0, wprowadzając nowe API, całkowicie usunąć Pythona 2.7, w tym wsparcie dla Qt4 i PyQt4. Nowe funkcje w Pythonie wprowadzeniu pierwszego etapu zostanie utrzymana, biorąc pod uwagę cały kod Python i postępów w wersjach 2.x QGIS kontynuować prace nad wersjami 3.x QGIS. W tej fazie oczekuje się także wprowadzania zmian w interfejsie API QGIS, które mogą złamać niektóre wtyczki. Aby rozwiązać ten zapewni migrację poradnictwo aa próbować ułatwić migrację wersji 2.x QGIS 3.x QGIS wersje.

Emitator z ostrzeżeniem

Istnieje kilka sztuczek, które powinny zostać wprowadzone w celu zapewnienia, że ​​migracja do QGIS 3.0 brzmi mniej bolesna.

• 1. SNależy zauważyć, że chociaż podejście przedstawione powyżej stara się zminimalizować ilość pracy nad skryptami Pythona we wtyczkach, niekoniecznie będzie to 100%. Najprawdopodobniej będą przypadki, w których kod będzie musiał zostać zmodyfikowany, a przynajmniej we wszystkich przypadkach będzie musiał zostać poprawiony, aby zapewnić, że nadal będzie działał poprawnie.
  2. Nie ma formalnie ustalonych środków finansowych na opłacenie deweloperów, którzy dobrowolnie poświęcają swój czas na ten proces migracji. Z tego powodu bardzo trudno będzie podać dokładne ramy czasowe, jak długo będzie trwać każda część procesu. Podczas planowania należy wziąć pod uwagę tę niepewność. Darowizny są oczywiście mile widziane, aby tak się stało.
  3. Mogą istnieć programiści i instytucje, które finansują nowe funkcje dla serii QGIS 2.x, co może wpłynąć na twoją pracę. Konieczne jest uwzględnienie w planach i budżetach tych projektów pewnej alokacji, aby stawić czoła migracji na platformę QGIS 3.x.
  4. Jeśli zespół QGIS pracuje nad „całkowitą zmianą”, nastąpi stosunkowo krótki czas, w którym QGIS będzie niestabilny i stale się zmienia z powodu ciągłych aktualizacji QGIS 3.0.
  4. Jeśli programujesz w „ewolucyjny” sposób, ryzykujesz, że rozwój 3.0 może potrwać dłużej, chyba że masz lojalną grupę programistów pracujących nad tym i przygotowujących go do przeniesienia.

  Propozycje

W świetle wszystkich powyższych informacji zaproponowana jest jedna z następujących form działań:

1 Wniosek:

Opublikuj tymczasową wersję 2.16, a następnie rozpocznij pracę nad wersją 3.0 jako priorytet, z 8-miesięcznym oknem na rozwój. Zmiany wprowadzone w wersji 2.16 będą starały się być zgodne z wersją 3.0 (zobacz python3 / pytq5).

2 Wniosek:

Lunging raz 3.0 z bardziej rozszerzonym oknie okres w QT5, Python 3.0 i PyQt5 i poprosić deweloperom wykonywać swoją pracę w 3.0. Kontynuuj wersje 2.x w regularnych odstępach czasu, aż 3.0 będzie gotowy.

Alternatywne propozycje

Masz inną propozycję? QGIS jest zainteresowany poznaniem możliwych alternatyw. Jeśli chcesz złożyć ofertę, wyślij ją na adres tim@qgis.org z tematem „Propozycja QGIS 3.0”.

The Blog QGIS, gdzie wydano niniejszą publikację.