[Qgis-psc] Fwd: QGIS 4.0 publicly announced - right time for propose and implement breaking changes?

[Vedran Stojnović]

Hi Regis and Richard,

thank you very much for your comments. I think that you slightly
misunderstood the point what I am trying to say. Let me try to explain
better:

We aren't short on time to implement my examples/proposals, but we are
short on time to define *the concept of a way to propose breaking changes
for the next major release *(assuming we want to have it for 4.0) and only
then, possibly, discuss and implement some of these changes that I noted - *but
that's another topic*.

The examples that I gave are some things that *I would* *propose* (through
a new system) as a fundamental/breaking change - and they are coming from
my experience mostly as a QGIS user, QGIS instructor and GIS implementer,
not as a QGIS developer/contributor.

Some changes, feature requests and bug-fixes make sense only on a major
release and I think that they do not fit well as QEP.
But these proposed fundamental/breaking changes should definitely be (in my
opinion):
1) discussed by bigger audience - to see others point of view on same
change, because QGIS covers many fields of use,
2) reviewed and commented by core developers,
3) approved by someone from PSC,
[ 4) ] optionally, but not obligatorily, funded by QGIS organization - for
important changes that need more work

We have a concept of QEP which functions well, but I see QEP as a proposal
for new cutting edge feature implementation that hasn't existed yet, which
will bring it's own new possibilities and bugs.
Other problem with QEP is that it's targeted to developers.
Developers/companies propose a new feature and implementation details and
then themselves do the work and implement proposed feature. But, what if
I'm not a C++ developer?
What if I do not know at all how to implement a change? But I use QGIS
everyday and I do know, from personal experience with QGIS and other GIS
related software that something isn't implemented how it should be, or can
be changed in a way that better suits end users.

Of course, we can make a feature request as an issue on GitHub, but if it's
a breaking change no one will implement it because it will break automated
workflows, existing models, scripts and so on for who knows how many
users... My opinion is that this approach only pushes this feature request
to a "issues graveyard". Two of these examples are #29100 and #54509 - they
are definitely implementation mistakes and both of them should be fixed,
but who dares to make such a change when current implementation is present
for who knows how much time.
If you ask me, the only right time for these changes is on a major version
change and these changes should be properly documented so that users can
have easier/non frustrating transition to a new version.

I believe other users and developers have more examples like this and
that's my point with this email - to agree on concept for proposing
breaking changes and to make them visible and discuss-able.
Should it be like QEP process, or just a label and milestone mark in GitHub
issues...??? We're only 6 months away from major update, but there is no
4.0 Milestone on GitHub, additional to that we have only one label that
marks breaking change and that is "API Break!".

Personally, I'm a bigger fan of a QEP process type - I would love to see
something like "QBCP" (QGIS Breaking Change Proposal) process, e.g.:
- two months for collecting proposals - well described, each proposal
having it's own page
- one month for discussion and decisions on what to accept / reject /
postpone till next major version
- two months for development sprint and preparing documentation on accepted
breaking changes in new version
- one month for finishing touches

Differently from QEP, the one that proposes QBCP doesn't need to know
anything about programming, just to point out (and well describe and
provide valid arguments) a breaking change for new version. Core developers
should be able to immediately reject and close proposal if recognized as
too complicated or not doable for any reason.

My only goal is to make QGIS more friendly by default and better suited for
end user. I hope that my idea is now clearer.

Sorry for long email and thank you for reading.

-- 
Srdačan pozdrav / Kind regards,
Vedran Stojnović.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20250425/a9fc6f8a/attachment.htm>