[QGIS-Developer] QGIS 4.0 - let's start some early discussions!

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[QGIS-Developer] QGIS 4.0 - let's start some early discussions!

Nyall Dawson
Hi all,

Following conversation from https://github.com/qgis/QGIS/pull/30234, I
think it would be beneficial if we start the conversation happening
about QGIS 4.0, and to throw some thoughts about timelines out there.

**Before anyone panics -- I'm expecting multi-year time frames here!
But I think we should START this discussion, and have at least some
idea of the time frames we're all aiming toward for a future 4.0
release.**

For reference: Qt upstream has previously hinted at November 2020 for
Qt 6, at which stage support for 5.x will be dropped. Discussions so
far are moving toward Qt 6 being a "gentle" cleaning, so there's
likely (hopefully?) not a lot we'll be forced to do to adapt to this.

I think we should aim for a similar goal -- a "gentle" API break, as
opposed to the huge-clean-and-break-everything-we-possibly-can
approach we took for 3.x (with good reason!).

Thoughts?

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Nathan Woodrow
Personally, I'm a bit uncomfortable with any kind of API break if we can avoid it which means we don't need to call it 4.0 as that marks a major API break when bumping that version number?  Any reason we need to make it 4.0 and not just continue down the 3.x stream until we are forced to break APIS?

We should be able to migrate away from any API breaks in theory right? We couldn't for 3.0 because of all the SIP and Python 3 stuff but that shouldn't be the case in Qt 6 hopefully.

That is just my take.  We need to maintain a stable API for as long as possible if we can which I know you know I'm just double voicing it.

- Nathan

On Tue, Jun 25, 2019 at 7:42 PM Nyall Dawson <[hidden email]> wrote:
Hi all,

Following conversation from https://github.com/qgis/QGIS/pull/30234, I
think it would be beneficial if we start the conversation happening
about QGIS 4.0, and to throw some thoughts about timelines out there.

**Before anyone panics -- I'm expecting multi-year time frames here!
But I think we should START this discussion, and have at least some
idea of the time frames we're all aiming toward for a future 4.0
release.**

For reference: Qt upstream has previously hinted at November 2020 for
Qt 6, at which stage support for 5.x will be dropped. Discussions so
far are moving toward Qt 6 being a "gentle" cleaning, so there's
likely (hopefully?) not a lot we'll be forced to do to adapt to this.

I think we should aim for a similar goal -- a "gentle" API break, as
opposed to the huge-clean-and-break-everything-we-possibly-can
approach we took for 3.x (with good reason!).

Thoughts?

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Tim Sutton-6
Hi



On 25 Jun 2019, at 12:27, Nathan Woodrow <[hidden email]> wrote:

Personally, I'm a bit uncomfortable with any kind of API break if we can avoid it which means we don't need to call it 4.0 as that marks a major API break when bumping that version number?  Any reason we need to make it 4.0 and not just continue down the 3.x stream until we are forced to break APIS?

We should be able to migrate away from any API breaks in theory right? We couldn't for 3.0 because of all the SIP and Python 3 stuff but that shouldn't be the case in Qt 6 hopefully.

That is just my take.  We need to maintain a stable API for as long as possible if we can which I know you know I'm just double voicing it.


If the Qt6 is broken (even gently :-P) and we plan to base QGIS 4 on it then even if our stuff is API compatible, the surrounding things that plugin authors have used may be broken, which would for me still justify calling it 4.0 instead of 3.x. 

Regards

Tim

- Nathan

On Tue, Jun 25, 2019 at 7:42 PM Nyall Dawson <[hidden email]> wrote:
Hi all,

Following conversation from https://github.com/qgis/QGIS/pull/30234, I
think it would be beneficial if we start the conversation happening
about QGIS 4.0, and to throw some thoughts about timelines out there.

**Before anyone panics -- I'm expecting multi-year time frames here!
But I think we should START this discussion, and have at least some
idea of the time frames we're all aiming toward for a future 4.0
release.**

For reference: Qt upstream has previously hinted at November 2020 for
Qt 6, at which stage support for 5.x will be dropped. Discussions so
far are moving toward Qt 6 being a "gentle" cleaning, so there's
likely (hopefully?) not a lot we'll be forced to do to adapt to this.

I think we should aim for a similar goal -- a "gentle" API break, as
opposed to the huge-clean-and-break-everything-we-possibly-can
approach we took for 3.x (with good reason!).

Thoughts?

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit 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

I'd love to connect. Here's my calendar link to make finding time easy.


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

3nids
In reply to this post by Nyall Dawson
Hi Nyall,

Thanks for raising this.

Le mar. 25 juin 2019 à 11:42, Nyall Dawson <[hidden email]> a écrit :
Hi all,

Following conversation from https://github.com/qgis/QGIS/pull/30234, I
think it would be beneficial if we start the conversation happening
about QGIS 4.0, and to throw some thoughts about timelines out there.

**Before anyone panics -- I'm expecting multi-year time frames here!
But I think we should START this discussion, and have at least some
idea of the time frames we're all aiming toward for a future 4.0
release.**

For reference: Qt upstream has previously hinted at November 2020 for
Qt 6, at which stage support for 5.x will be dropped. Discussions so
far are moving toward Qt 6 being a "gentle" cleaning, so there's
likely (hopefully?) not a lot we'll be forced to do to adapt to this.

I think we should aim for a similar goal -- a "gentle" API break, as
opposed to the huge-clean-and-break-everything-we-possibly-can
approach we took for 3.x (with good reason!).

Thoughts?

Personaly, I'd like to decide wether we stick to PyQt6 or move to Python for Qt and its shiboken for QGIS 4.
That would be the occasion to drop sipify for something a bit more robust (hum).
Investigations shall be pursued to see if we can safely move to Qt without any issue, but I guess that's hard to tell without trying. 

Denis

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Nyall Dawson
In reply to this post by Nathan Woodrow
On Tue, 25 Jun 2019 at 20:28, Nathan Woodrow <[hidden email]> wrote:
>
> Personally, I'm a bit uncomfortable with any kind of API break if we can avoid it which means we don't need to call it 4.0 as that marks a major API break when bumping that version number?  Any reason we need to make it 4.0 and not just continue down the 3.x stream until we are forced to break APIS?

Eventually, at some time we'll have to break API, and release 4.0. I'd
like us to start **thinking** and planning for that now, even if the
actual release doesn't happen for 2+ years (as is likely).

I mean, I think we'd all agree that there is things we could improve
upon from the 3.0 experience. If we leave this discussion for another
22 months, and then are forced to make a bunch of tricky decisions in
a matter of days, it's not exactly ideal :P Long term planning is
**always** going to beneficial!

Nyall

>
> We should be able to migrate away from any API breaks in theory right? We couldn't for 3.0 because of all the SIP and Python 3 stuff but that shouldn't be the case in Qt 6 hopefully.
>
> That is just my take.  We need to maintain a stable API for as long as possible if we can which I know you know I'm just double voicing it.
>
> - Nathan
>
> On Tue, Jun 25, 2019 at 7:42 PM Nyall Dawson <[hidden email]> wrote:
>>
>> Hi all,
>>
>> Following conversation from https://github.com/qgis/QGIS/pull/30234, I
>> think it would be beneficial if we start the conversation happening
>> about QGIS 4.0, and to throw some thoughts about timelines out there.
>>
>> **Before anyone panics -- I'm expecting multi-year time frames here!
>> But I think we should START this discussion, and have at least some
>> idea of the time frames we're all aiming toward for a future 4.0
>> release.**
>>
>> For reference: Qt upstream has previously hinted at November 2020 for
>> Qt 6, at which stage support for 5.x will be dropped. Discussions so
>> far are moving toward Qt 6 being a "gentle" cleaning, so there's
>> likely (hopefully?) not a lot we'll be forced to do to adapt to this.
>>
>> I think we should aim for a similar goal -- a "gentle" API break, as
>> opposed to the huge-clean-and-break-everything-we-possibly-can
>> approach we took for 3.x (with good reason!).
>>
>> Thoughts?
>>
>> Nyall
>> _______________________________________________
>> QGIS-Developer mailing list
>> [hidden email]
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Martin Dobias
In reply to this post by Nyall Dawson
Hi

On Tue, Jun 25, 2019 at 11:42 AM Nyall Dawson <[hidden email]> wrote:

>
> For reference: Qt upstream has previously hinted at November 2020 for
> Qt 6, at which stage support for 5.x will be dropped. Discussions so
> far are moving toward Qt 6 being a "gentle" cleaning, so there's
> likely (hopefully?) not a lot we'll be forced to do to adapt to this.
>
> I think we should aim for a similar goal -- a "gentle" API break, as
> opposed to the huge-clean-and-break-everything-we-possibly-can
> approach we took for 3.x (with good reason!).
>
> Thoughts?

Yeah it would make sense to align QGIS 4 with a jump in technology
(i.e. Qt5 -> Qt6). Maybe we could also investigate the option to use
Qt for Python (which is now a fully supported part of Qt) and free us
from PyQt and SIP (but the question still to be answered is whether Qt
for Python is at least as good as PyQt implementation).

For timing how about something like "not earlier than in 2 years and
not later than in 4 years" :-)

My observation is that lots of people are still using 2.x as we kind
of made people scared of upgrading (due to the API changes, missing
plugins etc.) and they got quite conservative. As people only now
slowly move to 3.x I think that's another reason why we should not
push for a 4.0 release too early.

In any case, this is a very useful discussion to have - and get
everyone on the same page.

Cheers
Martin
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Raymond Nijssen
In reply to this post by Nyall Dawson
Not sure about the changes in QT 6 but I think if the API breaks we
should call it QGIS 4.

And when the API breaks anyway, I would love to have the geometry model
improved and am willing to help.

Raymond


On 25-06-19 11:41, Nyall Dawson wrote:

> Hi all,
>
> Following conversation from https://github.com/qgis/QGIS/pull/30234, I
> think it would be beneficial if we start the conversation happening
> about QGIS 4.0, and to throw some thoughts about timelines out there.
>
> **Before anyone panics -- I'm expecting multi-year time frames here!
> But I think we should START this discussion, and have at least some
> idea of the time frames we're all aiming toward for a future 4.0
> release.**
>
> For reference: Qt upstream has previously hinted at November 2020 for
> Qt 6, at which stage support for 5.x will be dropped. Discussions so
> far are moving toward Qt 6 being a "gentle" cleaning, so there's
> likely (hopefully?) not a lot we'll be forced to do to adapt to this.
>
> I think we should aim for a similar goal -- a "gentle" API break, as
> opposed to the huge-clean-and-break-everything-we-possibly-can
> approach we took for 3.x (with good reason!).
>
> Thoughts?
>
> Nyall
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Matthias Kuhn 🌍
Hi,

There's already a wishlist of what could be done there:

   https://github.com/qgis/qgis4.0_api/issues

Maybe you can add your ideas to this list, Raymond (and others).

I am also in favor of waiting at least 2+ more years before doing a
major upgrade to give users some investment security when migrating and
deploying their systems.

And with a good communication about a "gentle" break I'm confident that
we'll have it easier this time.

Furthermore, it would be nice to go over this list of issues and see
what we can actually already can make happen before and deprecate, so
pyqgis devs can even have a smoother experience by being able to develop
against a future API even before. (Thinking about
https://github.com/qgis/qgis4.0_api/issues/90 and smilar here)

Regards

Matthias

On 6/25/19 1:37 PM, Raymond Nijssen wrote:

> Not sure about the changes in QT 6 but I think if the API breaks we
> should call it QGIS 4.
>
> And when the API breaks anyway, I would love to have the geometry
> model improved and am willing to help.
>
> Raymond
>
>
> On 25-06-19 11:41, Nyall Dawson wrote:
>> Hi all,
>>
>> Following conversation from https://github.com/qgis/QGIS/pull/30234, I
>> think it would be beneficial if we start the conversation happening
>> about QGIS 4.0, and to throw some thoughts about timelines out there.
>>
>> **Before anyone panics -- I'm expecting multi-year time frames here!
>> But I think we should START this discussion, and have at least some
>> idea of the time frames we're all aiming toward for a future 4.0
>> release.**
>>
>> For reference: Qt upstream has previously hinted at November 2020 for
>> Qt 6, at which stage support for 5.x will be dropped. Discussions so
>> far are moving toward Qt 6 being a "gentle" cleaning, so there's
>> likely (hopefully?) not a lot we'll be forced to do to adapt to this.
>>
>> I think we should aim for a similar goal -- a "gentle" API break, as
>> opposed to the huge-clean-and-break-everything-we-possibly-can
>> approach we took for 3.x (with good reason!).
>>
>> Thoughts?
>>
>> Nyall
>> _______________________________________________
>> QGIS-Developer mailing list
>> [hidden email]
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

pcav
Hi all,

On 25/06/19 13:46, Matthias Kuhn wrote:

> And with a good communication about a "gentle" break I'm confident that
> we'll have it easier this time.

agreed fully, good communication on these matters is of crucial
importance to let people accept new versions at move at the appropriate
time, to minimize noise.
Given the wide variety of networks, it will be difficult to properly
spread the tight word. Maybe we should have *official announcements* in
these occasions.
Also, I think the already proposed dynamic qgis access page could help a
lot here.
Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

C Hamilton
Let me share my experience with the jump from QGIS 2 to QGIS 3. I have been trying to get QGIS used by the US Government and make it an option rather than just relying on ESRI. This has been very difficult but I was making progress. I had offices that were primarily using QGIS and who were developing scripts to handle their work flow. When QGIS 3 came out they got so frustrated with the lack of documentation and the complete break of the API, with no program that would take their scripts and make them QGIS 3 compatible, that they completely abandoned QGIS and went back to ESRI. Despite the fact that I love QGIS 3 and think it is better than QGIS 2, I find there is now less interest in using QGIS. I have less customers then I used to have and it will probably take at least another year or two to get back to where I was at.

I know that as developers we want to continue to improve the code, add new features, and have a fun time. Fun tends not to be associated with documentation. I cannot tell you how important the documentation and training materials are. I would prefer seeing less new features but make sure the documentation is excellent and up-to-date. The PyQGIS documentation really needs a lot of work. It is not sufficient to let the functions and variable names explain what they do. Each variable needs to explained in such a way that the programmer will understand what effect it will have when they change the values. This is one thing that ESRI has done well - provide tons of documentation and training.

I hope these observations will be helpful to you as you plan QGIS 4. I don't want to go through what I have been going through with QGIS 3.

Cheers,

Calvin

On Tue, Jun 25, 2019 at 11:33 AM Paolo Cavallini <[hidden email]> wrote:
Hi all,

On 25/06/19 13:46, Matthias Kuhn wrote:

> And with a good communication about a "gentle" break I'm confident that
> we'll have it easier this time.

agreed fully, good communication on these matters is of crucial
importance to let people accept new versions at move at the appropriate
time, to minimize noise.
Given the wide variety of networks, it will be difficult to properly
spread the tight word. Maybe we should have *official announcements* in
these occasions.
Also, I think the already proposed dynamic qgis access page could help a
lot here.
Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

James Shaeffer

+1 for this.

 

--

James

 

From: QGIS-Developer <[hidden email]> On Behalf Of C Hamilton
Sent: Tuesday, June 25, 2019 9:16 AM
To: Paolo Cavallini <[hidden email]>
Cc: qgis-developer <[hidden email]>
Subject: Re: [QGIS-Developer] QGIS 4.0 - let's start some early discussions!

 

Let me share my experience with the jump from QGIS 2 to QGIS 3. I have been trying to get QGIS used by the US Government and make it an option rather than just relying on ESRI. This has been very difficult but I was making progress. I had offices that were primarily using QGIS and who were developing scripts to handle their work flow. When QGIS 3 came out they got so frustrated with the lack of documentation and the complete break of the API, with no program that would take their scripts and make them QGIS 3 compatible, that they completely abandoned QGIS and went back to ESRI. Despite the fact that I love QGIS 3 and think it is better than QGIS 2, I find there is now less interest in using QGIS. I have less customers then I used to have and it will probably take at least another year or two to get back to where I was at.

 

I know that as developers we want to continue to improve the code, add new features, and have a fun time. Fun tends not to be associated with documentation. I cannot tell you how important the documentation and training materials are. I would prefer seeing less new features but make sure the documentation is excellent and up-to-date. The PyQGIS documentation really needs a lot of work. It is not sufficient to let the functions and variable names explain what they do. Each variable needs to explained in such a way that the programmer will understand what effect it will have when they change the values. This is one thing that ESRI has done well - provide tons of documentation and training.

 

I hope these observations will be helpful to you as you plan QGIS 4. I don't want to go through what I have been going through with QGIS 3.

 

Cheers,

 

Calvin

 

On Tue, Jun 25, 2019 at 11:33 AM Paolo Cavallini <[hidden email]> wrote:

Hi all,

On 25/06/19 13:46, Matthias Kuhn wrote:

> And with a good communication about a "gentle" break I'm confident that
> we'll have it easier this time.

agreed fully, good communication on these matters is of crucial
importance to let people accept new versions at move at the appropriate
time, to minimize noise.
Given the wide variety of networks, it will be difficult to properly
spread the tight word. Maybe we should have *official announcements* in
these occasions.
Also, I think the already proposed dynamic qgis access page could help a
lot here.
Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Anita Graser
In reply to this post by C Hamilton
Hi Calvin,

On Tue, Jun 25, 2019 at 6:16 PM C Hamilton <[hidden email]> wrote:
 I had offices that were primarily using QGIS and who were developing scripts to handle their work flow. When QGIS 3 came out they got so frustrated with the lack of documentation and the complete break of the API, with no program that would take their scripts and make them QGIS 3 compatible, that they completely abandoned QGIS and went back to ESRI. Despite the fact that I love QGIS 3 and think it is better than QGIS 2, I find there is now less interest in using QGIS. I have less customers then I used to have and it will probably take at least another year or two to get back to where I was at. 

I agree that there is a problem here. 

I know that as developers we want to continue to improve the code, add new features, and have a fun time. Fun tends not to be associated with documentation. I cannot tell you how important the documentation and training materials are. I would prefer seeing less new features but make sure the documentation is excellent and up-to-date. 

I don't agree with the implied solution (i.e. slowing down development to focus on documentation) because I don't see how this is economically feasible.

If those offices that switched back from QGIS to ESRI would have invested the money they are now paying for licenses into QGIS, we could probably have fulfilled Tim's vision of having someone working full-time on QGIS documentation and Q&A. 

They could also have hired a developer to write the missing documentation. Or hired someone to port their scripts. Or stayed with QGIS 2 until more documentation is ready ...

This story is sad and frustrating but we need to find an economically feasible solution and I think that involved educating users about how open source projects work. 

Regards,
Anita



_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

C Hamilton


I don't agree with the implied solution (i.e. slowing down development to focus on documentation) because I don't see how this is economically feasible.

If those offices that switched back from QGIS to ESRI would have invested the money they are now paying for licenses into QGIS, we could probably have fulfilled Tim's vision of having someone working full-time on QGIS documentation and Q&A. 

They could also have hired a developer to write the missing documentation. Or hired someone to port their scripts. Or stayed with QGIS 2 until more documentation is ready ...

This story is sad and frustrating but we need to find an economically feasible solution and I think that involved educating users about how open source projects work.
 
Most of out QGIS users are using it because they have the interest and want to use open source. Management is tolerating its use and in this situation the users are not in a position to either hire a developer nor pay someone to write the documentation. That has to come form above. There are government entities that are supporting QGIS who have contributed significantly, but that doesn't necessarily translate down to individual offices and users.

I don't know what the solution is, but just know that this is what some face and the less API breaks, better documentation, and better transition methods can make a huge difference for these offices.

In the government users normally do not see the actual cost of ESRI licenses so if QGIS does not work out they just go back to ArcGIS. There are real benefits to QGIS. Users of ArcGIS occasionally feel the impact of the licenses being exhausted or the license server going down. QGIS does not have this problem. Additionally, QGIS normally runs faster, crashes, less, and can work with larger amounts of data. 

The one thing I see with many users is that they just want to do their job. They don't like redoing scripts they worked so hard on. They just want to run the software year after year and have it work.

Calvin

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Nyall Dawson
In reply to this post by Martin Dobias
On Tue, 25 Jun 2019 at 21:13, Martin Dobias <[hidden email]> wrote:

> Yeah it would make sense to align QGIS 4 with a jump in technology
> (i.e. Qt5 -> Qt6). Maybe we could also investigate the option to use
> Qt for Python (which is now a fully supported part of Qt) and free us
> from PyQt and SIP (but the question still to be answered is whether Qt
> for Python is at least as good as PyQt implementation).

This seems like a recurring theme. Let's add it to our api break
tracker so we've got a record.

For me, the biggest pain point in current API relates to all the use
of CRS database id values. These are redundant, fragile, and block us
from some nice features we should have through proj 6. I'd very much
like to kill these and require AUTH:ID codes everywhere, but that's a
break. I've hacked around it as best I can for now, but it IS limiting
the extent we can utilise the new world of projections.

> For timing how about something like "not earlier than in 2 years and
> not later than in 4 years" :-)

Works for me. Especially if Qt 6 is targeted for end of next year,
that would give us ~1 year to hold off a transition. (Although,
potentially if Qt6 is a minor break we'll likely be able to get qgis
building on both 5/6. It's just... plugins... which are the issue.
again.).

Nyall

> My observation is that lots of people are still using 2.x as we kind
> of made people scared of upgrading (due to the API changes, missing
> plugins etc.) and they got quite conservative. As people only now
> slowly move to 3.x I think that's another reason why we should not
> push for a 4.0 release too early.
>
> In any case, this is a very useful discussion to have - and get
> everyone on the same page.
>
> Cheers
> Martin
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Nyall Dawson
In reply to this post by C Hamilton
On Wed, 26 Jun 2019 at 02:16, C Hamilton <[hidden email]> wrote:
>
> Let me share my experience with the jump from QGIS 2 to QGIS 3. I have been trying to get QGIS used by the US Government and make it an option rather than just relying on ESRI. This has been very difficult but I was making progress. I had offices that were primarily using QGIS and who were developing scripts to handle their work flow. When QGIS 3 came out they got so frustrated with the lack of documentation and the complete break of the API, with no program that would take their scripts and make them QGIS 3 compatible, that they completely abandoned QGIS and went back to ESRI. Despite the fact that I love QGIS 3 and think it is better than QGIS 2, I find there is now less interest in using QGIS. I have less customers then I used to have and it will probably take at least another year or two to get back to where I was at.
>
> I know that as developers we want to continue to improve the code, add new features, and have a fun time. Fun tends not to be associated with documentation. I cannot tell you how important the documentation and training materials are. I would prefer seeing less new features but make sure the documentation is excellent and up-to-date. The PyQGIS documentation really needs a lot of work. It is not sufficient to let the functions and variable names explain what they do. Each variable needs to explained in such a way that the programmer will understand what effect it will have when they change the values. This is one thing that ESRI has done well - provide tons of documentation and training.
>
> I hope these observations will be helpful to you as you plan QGIS 4. I don't want to go through what I have been going through with QGIS 3.

Hey Calvin,

This feedback is SO invaluable to the project, thanks for submitting it!

Nyall

** SNARK: for what it's worth, we're not the only ones with crap API
migration docs. I recently had the extreme misfortune of having to
port some javascript from the ESRI ArcGIS JS library v3 to v4. Apart
from a handful of scattered notes, the migration docs are effectively
one paragraph: "Version 4.x is a substantial overhaul of the ArcGIS
API for JavaScript and its mapping components. Consider rewriting
applications instead of simply trying to update them.". In comparison,
the QGIS 3 api break documentation are pure gold.



>
> Cheers,
>
> Calvin
>
> On Tue, Jun 25, 2019 at 11:33 AM Paolo Cavallini <[hidden email]> wrote:
>>
>> Hi all,
>>
>> On 25/06/19 13:46, Matthias Kuhn wrote:
>>
>> > And with a good communication about a "gentle" break I'm confident that
>> > we'll have it easier this time.
>>
>> agreed fully, good communication on these matters is of crucial
>> importance to let people accept new versions at move at the appropriate
>> time, to minimize noise.
>> Given the wide variety of networks, it will be difficult to properly
>> spread the tight word. Maybe we should have *official announcements* in
>> these occasions.
>> Also, I think the already proposed dynamic qgis access page could help a
>> lot here.
>> Cheers.
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS.ORG Chair:
>> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>> _______________________________________________
>> QGIS-Developer mailing list
>> [hidden email]
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

pcav
In reply to this post by C Hamilton
Hi Calvin,
thanks for your feedback from "out in the field", it's very valuable for
the project. I understand very well your frustration.

On 25/06/19 20:26, C Hamilton wrote:

> I don't know what the solution is, but just know that this is what some
> face and the less API breaks, better documentation, and better
> transition methods can make a huge difference for these offices.

The solution can only be investing more in documentation and in
migration tools. We held migration for as long as it was reasonably
possible, a move to Qt5 and Py3 was necessary at that stage.
The point is who is going to put these resources (money and, more
importantly, manpower).
I think QGIS.ORG and the whole community is doing miracles with our
limited budget, one could hardly do more.

> In the government users normally do not see the actual cost of ESRI
> licenses so if QGIS does not work out they just go back to ArcGIS. There
> are real benefits to QGIS. Users of ArcGIS occasionally feel the impact
> of the licenses being exhausted or the license server going down. QGIS
> does not have this problem. Additionally, QGIS normally runs faster,
> crashes, less, and can work with larger amounts of data. 

Do you have hard evidence of these facts? It would be very useful to
share and to show it in the open.

> The one thing I see with many users is that they just want to do their
> job. They don't like redoing scripts they worked so hard on. They just
> want to run the software year after year and have it work.

so why they don't just keep on using 2.18 then? Of course it's
unsupported, and we recommend migrating, but we are not forcing users in
any way.
Cheers.

--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Even Rouault-2
In reply to this post by Nyall Dawson
> For me, the biggest pain point in current API relates to all the use
> of CRS database id values. These are redundant, fragile, and block us
> from some nice features we should have through proj 6. I'd very much
> like to kill these and require AUTH:ID codes everywhere, but that's a
> break. I've hacked around it as best I can for now, but it IS limiting
> the extent we can utilise the new world of projections.

How would you handle custom CRS (for example WKT definitions) that aren't
registered by a authority ?

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Nyall Dawson
On Wed, 26 Jun 2019 at 21:21, Even Rouault <[hidden email]> wrote:

>
> > For me, the biggest pain point in current API relates to all the use
> > of CRS database id values. These are redundant, fragile, and block us
> > from some nice features we should have through proj 6. I'd very much
> > like to kill these and require AUTH:ID codes everywhere, but that's a
> > break. I've hacked around it as best I can for now, but it IS limiting
> > the extent we can utilise the new world of projections.
>
> How would you handle custom CRS (for example WKT definitions) that aren't
> registered by a authority ?

I'd keep the existing custom-user srs db, and the current approach of
assigning these "USER:10001" type codes. It's anything relying on the
internal srsId (db row id) and srid (postgis id?!?!?!) which need to
be killed.

Nyall

>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Geo DrinX
In reply to this post by C Hamilton


Il giorno mar 25 giu 2019 alle ore 18:16 C Hamilton <[hidden email]> ha scritto:
Let me share my experience with the jump from QGIS 2 to QGIS 3. I have been trying to get QGIS used by the US Government and make it an option rather than just relying on ESRI. This has been very difficult but I was making progress. I had offices that were primarily using QGIS and who were developing scripts to handle their work flow. When QGIS 3 came out they got so frustrated with the lack of documentation and the complete break of the API, with no program that would take their scripts and make them QGIS 3 compatible, that they completely abandoned QGIS and went back to ESRI. Despite the fact that I love QGIS 3 and think it is better than QGIS 2, I find there is now less interest in using QGIS. I have less customers then I used to have and it will probably take at least another year or two to get back to where I was at.

I know that as developers we want to continue to improve the code, add new features, and have a fun time. Fun tends not to be associated with documentation. I cannot tell you how important the documentation and training materials are. I would prefer seeing less new features but make sure the documentation is excellent and up-to-date. The PyQGIS documentation really needs a lot of work. It is not sufficient to let the functions and variable names explain what they do. Each variable needs to explained in such a way that the programmer will understand what effect it will have when they change the values. This is one thing that ESRI has done well - provide tons of documentation and training.

I hope these observations will be helpful to you as you plan QGIS 4. I don't want to go through what I have been going through with QGIS 3.


I'm wondering what need there was in changing the names of the functions to call in the api qgis 3.

Was it not easier to leave a formal compatibility with the past?

No one should have rewritten everything. porting would have been easier.

Can you indicate the discussion thread where this choice was approved?

thank you.

GeoDrinX

 

Cheers,

Calvin

On Tue, Jun 25, 2019 at 11:33 AM Paolo Cavallini <[hidden email]> wrote:
Hi all,

On 25/06/19 13:46, Matthias Kuhn wrote:

> And with a good communication about a "gentle" break I'm confident that
> we'll have it easier this time.

agreed fully, good communication on these matters is of crucial
importance to let people accept new versions at move at the appropriate
time, to minimize noise.
Given the wide variety of networks, it will be difficult to properly
spread the tight word. Maybe we should have *official announcements* in
these occasions.
Also, I think the already proposed dynamic qgis access page could help a
lot here.
Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: QGIS 4.0 - let's start some early discussions!

Spencer Gardner-2
In reply to this post by Raymond Nijssen
> This feedback is SO invaluable to the project, thanks for submitting it!
> Nyall
> ** SNARK: for what it's worth, we're not the only ones with crap API
> migration docs. I recently had the extreme misfortune of having to 
> port some javascript from the ESRI ArcGIS JS library v3 to v4. Apart
> from a handful of scattered notes, the migration docs are effectively
> one paragraph: "Version 4.x is a substantial overhaul of the ArcGIS
> API for JavaScript and its mapping components. Consider rewriting
> applications instead of simply trying to update them.". In comparison,
> the QGIS 3 api break documentation are pure gold.

I agree this is helpful feedback, and I can vouch that, at least in the USA, government agencies are often set up to favor the "security" of a license arrangement with a large corporation over the unknowns presented by a project like QGIS.

I wanted to offer a different take from the other side of the equation in the USA. I work for a firm that consults with government agencies, so the dynamics are a bit different. In my case, we've adopted QGIS pretty heavily--not exclusively, but nearly so. The big sell to our users had very little to do with documentation or the cleanliness of the API. The greatest selling point for us was the huge improvement in usability and features over ESRI products. In other words, my experience leads me to the exact opposite conclusion from Calvin: more and better features has proven the worth of QGIS to our users regardless of documentation issues.

That's not to say documentation doesn't matter. Improvements to documentation would be a great thing. But the transition from 2.x to 3.x for us was an easy sell because of the huge improvements in usability and stability.

I guess the takeaway is that some user groups are more affected by technical changes like an API break than other user groups.

Lastly, I can vouch for the poor quality of documentation from the proprietary GIS option(s) out there. Inertia seems to be the biggest problem QGIS faces at this point.

Thanks all for consistently putting out great software!
Spencer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer