Qgis

QGIS 3.0 - How, when and what; it implies

Many are asking ourselves:

When will QGIS 3.0 be released?

Last year (2015) the project team began to investigate when and how QGIS 3.0 was to be released. They promised, according to a post from Anita Graser, that they were going to clearly convey their plans to users and developers before launching QGIS 3.0. They have recently tried to expose some of the considerations for a QGIS 3.0 release and at the end of the post there is an opportunity for us to present our ideas.

Why 3.0?

QGis_LogoTypically a major version is reserved for times when a big change is made to your software's API. This break is not a trivial decision for the QGIS project since we are hundreds of thousands of users who depend on QGIS, both for our own use and for services provided to third parties.

Occasionally breaking the API is necessary to accommodate the upgrade of architecture with improved approaches, new libraries and corrections to decisions made in the past.

What are the consequences of breaking the API?

One of the reasons why this breaking of the API in QGIS 3.0 is that it will have a great impact, which could break the hundreds of developed plugins that would no longer be compatible with the new API and the authors of these would have to do a review of their developments to ensure compatibility with the new API.

The extent of the necessary changes depends to a large extent on:

  • How many changes to the API affect the current functionality.
    At how many points the plugin authors have used parts of the API that they would change.
  • What will be the main changes for 3.0?

There are four key areas you are looking to change in 3.0:

 

Qt4 update to QT5: This is the basic set of libraries that QGIS is built on top level, we speak of the CORE-functional level of the platform. QT also provides libraries to perform memory management, connectivity operations, and graphics management. Qt4 (which QGIS is currently based on) is currently not being developed by the Qt library maintainers and might have functionality issues with some platforms (eg OS X) and even make it easier to manage binary versions (eg Debian Testing and the next Debian release “Stretch”). The process of bringing QGIS to QT5 already has an important advance (mainly what Matthias Kuhn has done) that together with Marco Bernasocchi smoke on the Android "QField" based entirely on QT5. However, there are some limitations in getting the new QT5 up and running because of its impact on QGIS – in particular with web browser widgets (mainly used in Composer and also a few other places in QGIS).

Update PyQt4 to PyQt5: These are the relative changes to the Python language for Qt on which the QGIS Python API is based. It is proposed to change the library of QT5 C ++, it is also expected to move the Python library to PyQt5 so that the benefits of the new QT5 API in Python can be exploited.
Updating Python 2.7 to Python 3: Currently everything runs on Python 2.7. Python 3 is the latest version of python and is recommended by those leading that project. Python 2 is slightly incompatible with Python 3 (almost proportional to the incompatibility between QGIS 2 and Qgis 3). Many developers have made python Python 3 largely backward compatible with Python 2, but the backward compatibility is not that great.
Improving the QGIS API itself: One of the problems with maintaining API compatibility between versions is that you have to live with your design choices for the long haul. Every effort is made in QGIS not to break the API in a series of minor releases. Releasing a QGIS version for 3.0 with an API not currently supported will give us an opportunity to "clean house" by fixing things in the API that we are not compliant with. You can see a provisional list of Changes proposed for the 3.0 API.

How to support changing the 3.0 API

As already mentioned, version 3.0 will break with QGIS version 2.x and there is a chance that many plugins, existing applications and other code that are based on the current API will break. So what can be done to mitigate the changes? Matthias Kuhn, Jürgen Fischer, Nyall Dawson, Martin Dobias and other top developers have been looking for ways to mitigate the number of API break changes while continuing to advance the QGIS codebase being based on the next generation of libraries and its own internal API. During our last meeting of the QGIS Project Steering Committee we geofumed through various possibilities. The following table summarizes what Matthias Kuhn graciously summarized and that we have partly tried to transliterate in this article according to what Posted on your blog:


QGIS 2.14 LTR
QGIS 2.16 ??? QGIS 3.0
Release date End of February 4 months later 2.14 Cycle 8 Months?
Notes Update python code of core QGIS to be Python 3 compatible and PyQt5 compatible (partial implementation for key functionality eg console, python core plugins etc.)
Qt4 Si

Deprecated in Debian Stretch (due in a year)

(Webkit removed)

Yes No
Qt5 No

Misses QWebView - new replacement not on all platforms. Also misses QPainter Engine.

Si Si
PyQt4 Si Si No
PyQt5 No Si Si
Python 2 Si Si No
Python 3 No Si Si
API Cleanup No No Si
Wrappers
PyQt5 -> PyQt4
Provides ~ 90% Backwards Compatibility
No Si Si
Mainstream Binary Qt4 Based Qt4 Based Qt5 Based
Funding priority Python wrappers

There are two important things to keep in mind about Matias' proposal:

In the first phase, The work is done in the 2.x series to complete support for QT5, PyQt5, using Python 3.0, supporting Qt4, PyQt4 and Python 2.7. This implies that all changes made in the first phase would be compatible with earlier 2.x versions. It will incorporate Python functionalities will be introduced so that the old PyQt4 API can still be used especially when compiling against QT5, PyQt5, Python 3.0. When using QGIS compiled against Qt4, PyQt4 and Python 2.7 there would be no break compatibility.
In the second phase, You would work to produce QGIS 3.0, introducing the new API, it will completely eliminate Python 2.7, including support for Qt4 and PyQt4. The new python features introduced in the first phase will be retained, keeping in mind that all python code and developments for 2.x versions of QGIS will continue to work on 3.x versions of QGIS. In this phase you are also expected to introduce changes to the QGIS API that may break some plugins. To address this, we will provide a migration guide to try to facilitate the migration process from 2.x QGIS versions to 3.x QGIS versions.

Caveat emptor

There are a couple of tricks that should be put in place to ensure that migration to QGIS 3.0 sounds less painful.

  • 1. SIt should be noted that while the approach set out above tries to minimize the amount of work on python scripting in plugins, this will not necessarily be 100%. There will most likely be cases where the code has to be tweaked and in all cases at least, it will likely have to be revised in order to ensure that it continues to function properly.
    2. There is no formally established financial resource to pay developers who voluntarily invest their time for this migration process. Because of this, it will be very difficult to give exact time frames for how long each part of the process will take. This uncertainty must be taken into account in planning. Of course donations are welcome to help make this happen.
    3. There may be developers and institutions out there that are funding new features for QGIS 2.x series and this may affect your work. It is necessary to include in the plans and budgets of these projects, a certain allocation to face the migration to the QGIS 3.x platform.
    4. If the QGIS team works on a "total change", there will be a relatively short time during which QGIS will be unstable and constantly changing due to ongoing updates to QGIS 3.0.
    4. If you develop in an 'evolutionary' way, you run the risk that 3.0 development may take longer unless you have a loyal group of developers working on it and getting it ready to port.

    Presentation

In light of all the above information, one of the two lines of action is proposed:

1 Proposal:

Releasing an interim version 2.16 and then starting work on version 3.0 as a priority, with a development window of 8 months. Changes made in version 2.16 will seek to be compatible with version 3.0 (see python3 / pytq5).

2 Proposal:

Launch 3.0 at once with a longer duration window on QT5, Python 3.0 and PyQt5, and ask developers to do their work on 3.0. Continue with 2.x versions at regular intervals until 3.0 is ready.

Alternative proposals

Have an alternative proposal? QGIS is interested in knowing about possible alternatives. If you want to submit a proposal, please send to Tim@qgis.org with the subject “QGIS 3.0 Proposal”.

The QGIS blog, From where this publication came out.

Golgi Alvarez

Writer, researcher, specialist in Land Management Models. He has participated in the conceptualization and implementation of models such as: National Property Administration System SINAP in Honduras, Management Model of Joint Municipalities in Honduras, Integrated Cadastre-Registry Management Model in Nicaragua, Territory Administration System SAT in Colombia . Editor of the Geofumadas knowledge blog since 2007 and creator of the AulaGEO Academy that includes more than 100 courses on GIS - CAD - BIM - Digital Twins topics.

Related Articles

Leave a comment

Your email address will not be published. Required fields are marked with *

Back to top button