QGIS 3.0 - Как, кога и какво; това предполага

Мнозина се питат:

Кога ще бъде пусната QGIS 3.0?

Миналата година (2015) екипът на проекта започна да проучва кога и как да бъде пуснат QGIS 3.0. Те обещаха, според даден пост Анита Грасър, които те щяха ясно да предадат на потребителите и разработчиците на своите планове, преди да пуснат QGIS 3.0. Наскоро те се опитаха да изложат някои от съображенията за QGIS 3.0 и в края на публикацията има възможност да представим нашите идеи.

Защо 3.0?

Обикновено основната версия е запазена за времената, когато се прави голяма промяна в API на вашия софтуер. Това прекъсване не е тривиално решение за проекта QGIS, тъй като ние сме стотици хиляди потребители, които зависят от QGIS, както за собствена употреба, така и за услуги, предоставяни на трети страни.

От време на време се нарушава API, за да се адаптира актуализирането на архитектурата с подобрени подходи, нови библиотеки и корекции на решенията, взети в миналото.

Какви са последствията от счупването на API?

Една от причините, поради това нарушение на API в QGIS 3.0 е, че тя ще има по-голямо влияние, което може да се прекъсне стотици развитите плъгини, които вече няма да бъдат съвместими с новия API и авторите на тези трябва да направите, преглед на тяхното развитие, за да се осигури съвместимост с новия API.

Размерът на необходимите промени до голяма степен зависи от:

• Колко промени в приложния програмен интерфейс (API) засягат текущата функционалност.
  На колко точки авторите на приставките са използвали части от приложния програмен интерфейс, които биха променили.

• Какви ще бъдат основните промени за 3.0?

Има четири ключови области, които искате да промените в 3.0:

Qt4 актуализация на QT5: Това е основният набор от библиотеки, които QGIS е изграден на най-високо ниво, говорим за CORE-функционалното ниво на платформата. QT също така предоставя библиотеки за управление на паметта, операции за свързване и управление на графиката. Qt4 (на който в момента се базира QGIS) понастоящем не се разработва от поддържащите библиотеки Qt и може да има проблеми с функционалността с някои платформи (напр. OS X) и дори да улесни управлението на двоични версии (напр. Debian Testing и следващото издание на Debian "Опъвам, разтягам"). Процесът на въвеждане на QGIS в QT5 вече има важен напредък (основно това, което направи Матиас Кун), който заедно с Марко Бернасоки пушат на Android "QField", базиран изцяло на QT5. Въпреки това, има някои ограничения при стартиране и работа на новия QT5 поради въздействието му върху QGIS – по-специално с джаджи за уеб браузър (използвани основно в Composer, а също и на няколко други места в QGIS).

Актуализиране на PyQt4 на PyQt5: Тези промени са свързани с езика Python за Qt в приложния програмен интерфейс на QGIS Python се основава. Възниква промените QT5 C ++ библиотека, също се очаква да прехвърли на PyQt5 питон библиотека, така че те могат да се възползват от предимствата на новите интерфейси в Python QT5.
2.7: Актуализиране на Python 3 в Python В момента всичко работи на Python 2.7. Python 3 е най-новата версия на python и се препоръчва от ръководителите на този проект. Python 2 е леко несъвместим с Python 3 (почти пропорционален на несъвместимостта между QGIS 2 и Qgis 3). Много разработчици са направили python Python 3 до голяма степен обратно съвместим с Python 2, но обратната съвместимост не е толкова голяма.
Подобряване на самия QGIS API: Един от проблемите с поддържането на съвместимост на API между версиите е, че трябва да живеете с избора си на дизайн за дълго време. В QGIS се полагат всички усилия да не се нарушава API в серия от незначителни издания. Пускането на версия на QGIS за 3.0 с API, който в момента не се поддържа, ще ни даде възможност да „почистим къщата“, като поправим неща в API, с които не сме съвместими. Можете да видите временен списък на предложените промени за API 3.0.

Как да поддържате промяната на 3.0 API

Както вече споменахме, версия 3.0 ще се счупи с QGIS версия 2.x и има вероятност много плъгини, съществуващи приложения и друг код, базирани на текущия API, да се счупят. И така, какво може да се направи за смекчаване на промените? Матиас Кун, Юрген Фишер, Найъл Доусън, Мартин Добиас и други водещи разработчици търсят начини да намалят броя на промените в пробивите на API, като същевременно продължават да подобряват QGIS кодовата база, базирана на следващото поколение библиотеки и собствен вътрешен API. По време на последното ни заседание на Управителния комитет на проекта QGIS разгледахме различни възможности. Следващата таблица обобщава това, което Матиас Кун любезно е обобщил и че отчасти се опитахме да транслитерираме в тази статия според това, което публикуван в блога ви:

Има две важни неща, които трябва да имате предвид, за предложението на Матиас:

В първата фазаРаботата се извършва от поредицата, за да завършите 2.x подкрепа QT5, PyQt5 използване Python 3.0, подпомагане Qt4, PyQt4 и Python 2.7. Това означава, че всички промени, направени в първата фаза, биха били съвместими с по-ранните 2.x версии. Python функции ще бъдат включени ще бъдат въведени така, че старата API PyQt4 все още може да се използва, особено когато съставен срещу QT5, PyQt5, Python 3.0. При използване на QGIS, компилирано срещу Qt4, PyQt4 и Python 2.7, няма да има съвместимост при прекъсване.
Във втората фаза, той ще работи за производството на QGIS 3.0, въвеждайки новия API, той напълно ще премахне Python 2.7, включително поддръжка за Qt4 и PyQt4. Новите функции на Python, въведени в първата фаза, ще продължат, като се има предвид, че всички питън код и разработки за 2.x версиите на QGIS ще продължат да работят върху 3.x версиите на QGIS. На тази фаза се очаква също така да се въведат промени в QGIS API, които могат да нарушат някои приставки. За да се справим с това, ще предоставим ръководство за мигриране, за да се опитаме да улесним процеса на мигриране от 2.x QGIS версиите към версиите 3.x QGIS.

Обърнете внимание

Има няколко трика, които трябва да бъдат въведени, за да се гарантира, че миграцията към QGIS 3.0 звучи по-малко болезнена.

• 1. SТрябва да се отбележи, че докато горепосоченият подход се опитва да сведе до минимум количеството работа, което съществува при скриптове на python в приставките, това не е задължително 100%. Най-вероятно ще има случаи, при които кодът трябва да бъде променен и поне във всички случаи той ще трябва да бъде ревизиран, за да се увери, че продължава да функционира правилно.
  2. Няма официално установен финансов ресурс, който да плаща на разработчиците, които доброволно инвестират времето си за този процес на миграция. Поради това ще бъде много трудно да се дадат точни времеви рамки за това колко време ще отнеме всяка част от процеса. Тази несигурност трябва да се вземе предвид при планирането. Разбира се, даренията са добре дошли, за да помогнат за това.
  3. Възможно е да има разработчици и институции, които финансират нови функции за QGIS 2.x серия и това може да повлияе на работата ви. Необходимо е да се включат в плановете и бюджетите на тези проекти известна сума за посрещане на миграцията към платформата QGIS 3.x.
  4. Ако екипът на QGIS работи върху „пълна промяна“, ще има относително кратко време, през което QGIS ще бъде нестабилна и постоянно се променя поради текущите актуализации на QGIS 3.0.
  4. Ако развивате по „еволюционен“ начин, рискувате разработването на 3.0 да отнеме повече време, освен ако нямате лоялна група от разработчици, работещи върху него и подготвящи го за пренасяне.

  предложения

В светлината на горепосочената информация се предлага един от двата насоки на действие:

1 Предложение:

Издаване на междинна версия 2.16 и след това започване на работа по версия 3.0 като приоритет, с период на разработка от 8 месеца. Промените, направени във версия 2.16, ще се стремят да бъдат съвместими с версия 3.0 (вижте python3 / pytq5).

2 Предложение:

Стартирайте 3.0 едновременно с прозорец с по-дълга продължителност на QT5, Python 3.0 и PyQt5 и помолете разработчиците да работят върху 3.0. Продължете с 2.x версии на редовни интервали, докато 3.0 не е готов.

Алтернативни предложения

Имате ли алтернативно предложение? QGIS се интересува да знае за възможните алтернативи. Ако искате да подадете предложение, моля изпратете на tim@qgis.org с предмет “QGIS 3.0 Предложение”.

Трябва да следва QGIS блог, където тази публикация излезе.