Ok so quick spoiler here: there is no QGIS 3.0 ready yet, nor will there be a QGIS 3.0 for some time. This article provides a bit more detail on the plans for QGIS 3.0. A few weeks ago I wrote about some of the considerations for the 3.0 release, so you may want to read that first before continuing with this article as I do not cover the same ground here.

A lot of consideration has gone into deciding what the approach will be for the development of QGIS 3.0. Unfortunately the first PSC vote regarding which proposal to follow was a split decision (4 for, 3 against, 1 abstention and 1 suggestion for an alternative in the discussion). During our PSC meeting this week we re-tabled the topic and eventually agreed on Jürgen Fischer’s proposal (Jürgen is a QGIS PSC Member and the QGIS Release Manager) by a much more unanimous margin of 8 for, 1 neutral and 1 absent. Jürgen’s proposal is largely similar to the Proposal 2 described in my previous posting. I want to make some special notes here about our discussion and subsequent decision which will hopefully help to clarify the thinking behind our decision for other interested observers.  First let me lay out Jürgen’s plan in his own words:

“My preferred approach would still be:

• Do a Qt5/PyQt5/Python3 branch in parallel, actually work on it until it’s ready, make it master and release it as 3.0
• Meantime keep working on master (2.x) and keep releasing them every 4 months as usual

Everyone can work on the branch (s)he wants (or is hired to), but needs to consider if (s)he want to do it (or spend funds on):

• only for 2.x: knowing that it will be released soon; but might become unusable because platforms drop support for stuff it depends on sooner or later
• only for 3.x: not knowing when that will ever release or
• for both: knowing that work needs to be done twice.
• People adding features to the master branch will be responsible to ensure that their work gets merged to 3.0 branch.

As PSC we should maintain the environment for people to do something for QGIS – but we cannot tell them to – so we don’t have resources we can actually plan with and that means we can either release something when the big thing is ready or what we have in fixed intervals.” – Jürgen Fischer

What follows are some further details and clarifications to our preferred approach:

Why do parallel development?

Parallel development of 3.0 maintaining our master branch with 2.x code in it has advantages and disadvantages. First the advantages:

• If we encounter major technical difficulties / release blockers in the 3.0 branch, it will not impact on our normal 3 monthly release cycle.
• Our binary build systems (Linux, Windows and OSX binaries) will be unaffected until 3.0 is ready.
• It is very likely that building 3.0 binaries on different platforms is going to have difficulties for each platform. For example OSGEO4W has no Python3 and Qt5 packages yet. Someone needs to see to the creation of the required package as a separate exercise from the actuals development of a version of QGIS that will take advantage of these updated libraries. We don’t yet know what problems may be in countered in preparing these.
• “Don’t break what already works”: we have a working and relatively stable master branch and we don’t want to do a ‘cowboy stunt’ and break it. We prefer to wait until the 3.0 branch is mature, has passing tests and is known to work well before merging it into master and treating it as our ‘best we currently have’ master branch.

Of course nothing in life is completely easy, there are also some disadvantages:

• Some developers may feel that running two mainstream branches is dilution of effort. To counter this, our public recommendation is that after 2.16 comes out, all QGIS contributors are strongly encouraged to provide their patches against the 3.0 branch. Any features applied to the master branch is not guaranteed to be part of the 3.0 release.
• Regular merging of master to the 3.0 branch may prove more and more difficult over time as the two branches diverge more. Again we will strongly encourage that developers submitting new features after the 2.16 release do so against the 3.0 branch.
• 3.0 branch won’t have auto build system for nightly binaries in the beginning. Since we expect that the initial branch of 3.0 will break these anyway, Having a separate branch is actually an advantage here as it will give binary packages some time to get their build systems up to speed.

To clarify things for developers wondering where to commit their work: we discourage people from writing new features in master after 2.16 is released and rather ask them to make their changes in the 3.0 branch. Only those who really need to see their features in the next 2.18 release would have to dual commit.

Isn’t it better to work on 3.0 in the master branch?

Some queries have been raised about whether it would be better to rather work on 3.0 in the ‘master branch’ and relegate the 2.x code base to a side branch (instead of our intended approach which is to keep master tracking 2.x until 3.0 is ready and then merge it to master). We feel that keeping master tracking the 2.x code base is more conservative – it will not break existing packaging / build systems and if there is any major hitch in 3.0 development the release process will continue unabated based on the 2.x code set. While 3.0 is under development, package builders will have time to figure out the packaging process while still keeping the regular nightly builds against 2.x running. The implication of this is that 2.18 may contain only bug fixes which were applied to the 2.x branch and no significant new features.

The schedule will not be fixed

One thing that we want to make really clear (and was a key point in our many discussions) is that there will be no fixed release date for QGIS version 3.0. There are several reasons for this:

• As a steering committee, we can only set the QGIS ship pointing in a given direction, our power to actually make work happen is extremely limited. This is because we are a community made up largely of volunteer developers or developers working on a commission basis for third party clients. We have no say in how these contributors spend their time.
• We do not yet know which (if any) major technical issues will be encountered during the development of 3.0. Any such issues could very well delay the roll out of QGIS 3.0.

Instead our plan is to make the 2.16 release and then effectively move all developer effort to the 3.0 branch as best we can (through close liaison with our developer community).

To clarify things for those wondering when they will give 3.0 to their users: The actual release date for 3.0 its interterminate, but the general aim is still to try to encourage everyone to get it ready for 1 year from now. Remember that as an open source community we cannot directly ensure that project timelines are met since our developer force is largely volunteer based or work according to their own companies agendas.

Will 3.0 be a Long Term Release (LTR)?

It is our recommendation that we wait until 3.2 is ready before designating it an LTR – there are going to be large changes in the code base for 3.0 and we would rather stabilise things a bit before applying the LTR label to the release.

 

Looking forward to 3.0

Personally I am very much looking forward to the release of QGIS 3.0 – it represents another huge milestone in our project, it affords us a great opportunity to get rid of a lot of cruft out of our code base and API’s and it will arm us with a set of modern, new libraries that will see us through the next several years. Rock on QGIS 3.0!

QGIS PSC Chairman