[Qgis-psc] Draft announcement re 3.0

[Tim Sutton]

Hi PSC

I have written up a draft announcement about the 3.0 plan. I am including a complete draft below.. Please let me know if you have comments, corrections, additions to this DRAFT so that I can post it and then advertise it more broadly.

COPY BEGINS
— ——— — ————


QGIS 3.0 plans

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 <http://blog.qgis.org/2016/01/17/help-us-to-plan-for-qgis-3-0/> 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 <https://www.loomio.org/d/5MCdPwoL/vote-to-approve-the-process-for-qgis-3-0> 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 <http://blog.qgis.org/2016/01/17/help-us-to-plan-for-qgis-3-0/>. 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 yes 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.


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 our 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).



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


——————

COPY ENDS
—





Tim Sutton

Visit http://kartoza.com <http://kartoza.com/> to find out about open source:

* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services

Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee

Kartoza is a merger between Linfiniti and Afrispatial

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160207/937e91c6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timsutton.png
Type: image/png
Size: 5931 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160207/937e91c6/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KartozaLogo160x66.png
Type: image/png
Size: 9324 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160207/937e91c6/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160207/937e91c6/attachment.sig>