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 would clearly convey to the users and developers of their plans before launching QGIS 3.0. Recently they have tried to expose some of the considerations for a launch of QGIS 3.0 and at the end of the post there is an opportunity for us to present our ideas.

Why 3.0?

QGis_LogoNormally a major version is reserved for times when a big change is made to the API of your software. This break is not a trivial decision for the QGIS project since we are hundreds of thousands of users that depend on QGIS, both for their own use and for service 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 in which QGIS is built in top level, we talk about the CORE-functional level of the platform. The QT also provides libraries for mummy management, connectivity operations and graphics management. The Qt4 (on which QGIS is currently based) is not currently being developed by those responsible for the Qt library and could have problems in terms of functionality with some platforms (for example, OS X) and even facilitate the management of binary versions (for example Debian Testing and the next version of Debian "Stretch"). The process of bringing QGIS to QT5 already has an important breakthrough (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 launching the new QT5 because of its impact on QGIS - particularly with web browser widgets (mainly used in the Composer and also some 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 who lead that project. Python 2 is slightly incompatible with Python 3 (to an extent almost proportional to the incompatibility between QGIS 2 and Qgis 3). Many developers have made Python Python 3 largely compatible with earlier versions of Python 2, but the reverse compatibility is not as good.
Improving the QGIS API itself: One of the problems with which maintains API compatibility between versions is that you have to live with your design options for a long term. In QGIS, every effort is made not to break the API within a series of minor releases. Releasing a QGIS version for 3.0 with an API not compatible with the current will give an opportunity to "clean the house" by fixing things in the API that we are with which there is nonconformity. You can see a provisional list of the Changes proposed for the 3.0 API.

How to support changing the 3.0 API

As already mentioned, the 3.0 version will cause a break with the 2.x version of QGIS and there is a possibility that many plugins, existing applications and other codes 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 leading developers have been looking for ways to mitigate the number of API breakthroughs as the QGIS base code continues to be based on the next generation of libraries and their own internal APIs. During our last meeting of the Steering Committee of the Project QGIS was geofumó through several possibilities. The following table summarizes what Matthias Kuhn kindly summed up and that we have partly tried to transliterate in this article according to what Posted on your blog:

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
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 in python scripting in plugins, this will not necessarily be in an 100%. There will most likely be cases where the code has to be adjusted and in all cases at least it is likely to have to be reviewed 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 in this migration process. Because of this, it will be very difficult to give exact timelines on 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 who are funding new features for the 2.x QGIS series and this can affect their work. Included in the plans and budgets of these projects, some allocation to address the migration to the platform 3.x of QGIS.
    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 it develops in an "evolutionary" way, there is a risk that 3.0 development may take longer unless there is a faithful group of developers working on this and getting them ready to migrate.


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

1 Proposal:

Release a provisional 2.16 version and then start working on the 3.0 version as a priority, with a development window of 8 months. Changes made in the 2.16 version will look to be compatible with the 3.0 version (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

Do you have an alternative proposal? QGIS is interested in knowing of possible alternatives. If you wish to submit a proposal, please send Tim@qgis.org with the subject "QGIS 3.0 Proposal".

The QGIS blog, From where this publication came out.

Leave an answer

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.