Loomio
Sun 24 Jan 2016 8:59PM

Vote to approve the process for QGIS 3.0

TS Tim Sutton Public Seen by 285

Recently I posted a blog post (http://blog.qgis.org/2016/01/17/help-us-to-plan-for-qgis-3-0/) summarising the considerations on how we should go about the process of putting out a QGIS 3.0 release. At the bottom of that posting is a proposal outlined by Matthias Kuhn. I created this thread so that we can agree or reject Matthias' proposal. In the situation where it is rejected, a viable alternative should be offered. Once we have an agreed upon roadmap, we should communicate this clearly to the greater QGIS user community.

For easy reference, here is Matthias' proposal:


QGIS 2.16 Release as usual in 4 months

-> PyQt5 Support
-> Python 3 Support
-> Wrapper library for PyQt4/PyQt5
-> Maybe a helper transition script that does 80% of the rewrite
-> All old plugins still work
-> Some python code is updated (console, plugin manager, processing) to
have some guidelines and experience how to update python code
-> For future debian, mac osx… versions there’s a qt5 version around
(with almost no plugins working)

During the same time: make some noise that QGIS 3 is coming and we need
everybody to put some money and dev time aside for it and that it’s
going to be amazing.

After that: 8 months break for 3.0 (maybe some betas after 4 months and
every month after)


AN

Andreas Neumann Thu 28 Jan 2016 2:38PM

We can spend some of our funds on the work for QGIS 3.0

JEF

Jürgen E. Fischer Thu 28 Jan 2016 2:54PM

Once we decided on process and timing we will certainly ask our core devs if they can contribute and how much.

Hm, and then revise the time frame to the available resources?

TS

Tim Sutton Thu 28 Jan 2016 2:57PM

@jef One option is to keep putting out 4 monthly releases but labelled as beta until we are happy that 3.0 is "good enough". That we can can deal with delays in a way that still gives people early access to the 3.0 featureset without having to freeze the API till we are ready.

JEF

Jürgen E. Fischer Thu 28 Jan 2016 3:09PM

That's also odd. Why release something that we know is not good enough? If it's not good enough to release, we could skip releases all together, live with nightlies and start releasing again when 3.0 actually becomes good enough (maybe for 4-12 months).

TS

Tim Sutton Fri 29 Jan 2016 6:36AM

@jef wrote:

That's also odd. Why release something that we know is not good enough? If it's not good enough to release, we could skip releases all together, live with nightlies and start releasing again when 3.0 actually becomes good enough (maybe for 4-12 months).

That sounds fine for me too....

TS

Tim Sutton Fri 29 Jan 2016 6:41AM

@richardduivenvoord and @paolocavallini The proposal from Matthias does not promote 2.16 as the next LTR (as I read it anyway). It proposes:

  • Release 2.14 LTR
  • Release 2.16 as a 'migration release' that people can use as a basis for already getting their code Qt5, Python 3 and PyQt5 ready.
  • Release 3.0 and people who have been working on porting their code on 2.16 only need to focus on porting their code to cope with API breaking changes in QGIS 3.0

@andreasneumann proposal to treat 2.16 is a separate discussion (see https://www.loomio.org/d/QqnsRaGg/ltr-versions-should-be-supported-for-2-years)

RD

Richard Duivenvoorde Fri 29 Jan 2016 8:01AM

Yes, that is clear to me.
It is just for the users that I want to end with a clear stable 2.x version.
And want to fully focus on getting ready for Qt5, Py3 & api 3.0
Telling our users that we are going to create another 2.x version (and maybe another one if that is 'needed'?) only leads to questions like Andreas' one: yes but can the last one then be a LTR (and if not now, we will hear it again when the migration to 3.0 takes a little longer then planned....).
We will need a bigger then 4 months window anyway to get a stable 3.0 anyway, so start with that asap. And do not promiss another 2.x version. IF users/companles want to stick to 2.x they can stick to 2.14 as a LTR as long as they want.
Give me one reason other then "we did not communicate" to have a 2.16. Because the communication point is (at least to me) not valid. Going to 2.16 only troubles our goals.
Maybe I sound a little black and white. But I think as a PSC we should stear as clear as possible. And I know communication is not our strongest point anyway, why would make 'communication' the most important argument now? Maybe we should spend more money on marketing instead of coding and docs >:P

AN

Andreas Neumann Fri 29 Jan 2016 8:39AM

@richardduivenvoord The main reason why I want to have 2.16 is that in Switzerland there a lot of projects where organisations want to move to QGIS for editing Geodata. The forms support we have in QGIS is about 90% there - but there are several bits missing that we need to allow for a good user experience for a GIS operator.

This concerns mainly forms, relations, widgets, and transactions - I have detailed proposals if you are interested. There is also money around to address these issues within the next 3-4 months.

These projects are on province and municipality level and several of the organizations need solutions this year (2016) - they can't wait until 3.0 is maybe mature enough in 2017. We are at the mercy of the QGIS.ORG board. If you move directly to 3.0 - we are quite screwed. We would then have to probably move to the Sourcepole QGIS enterprise solution.

So there is a really concrete and urgent demand for another 2.x release.

PC

Paolo Cavallini Fri 29 Jan 2016 10:33AM

I agree with @richardduivenvoord
My position:
* end up with 2.14 LTR
* start immediately with 3.0, and do all new stuff there
* in a few selected cases, if there are very good reasons, lift the feature freeze for LTR, and allow for extra functions to be backported, therefore avoiding the need for a 2.16

AN

Andreas Neumann Fri 29 Jan 2016 12:32PM

hm - is this a funny game where people change their mind every day or two?

Load More