[QGIS-Developer] Early 3.4 point release?

[Nyall Dawson]

On Wed, 31 Oct 2018 at 20:22, Matthias Kuhn <matthias at opengis.ch> wrote:

> But still then there will be issues and most people will only start
> testing the final release and we will run into "unknown issues" and
> "unreported issues" while working on QGIS and fix and push them without
> a big admin overhead. And we just have to accept that this is our life
> as software engineers and we all do the best we can :-)

Yep. 100% agree -- this is something we always must keep in mind in
these discussions. We'll never achieve a 100% regression free release,
it's just not possible given the complexity of QGIS. And probably has
never been done in the history of software development ever anyway!

In this particular case I don't see how we could have avoided it. It's
a "perfect storm" combination of:
1. Lack of clarity and huge warnings in the Qt docs about how an API
was designed to be used
2. QGIS developers relying on previous behavior of this API
3. Qt developers putting stronger checks preventing use of the API in
the way it wasn't designed, which as a result broke QGIS functionality
4. The bug only being visible in a highly GUI dependent setup -- it
relies on a very recent Qt version and QGIS network based request with
HTTPS in a background thread. Possibly we could/should have unit tests
for this, but it's a very difficult situation to test for and predict
in advance.
5. A QGIS release falling right at a time when a number of
platform/library upgrades occurred, which upgraded Qt to the newer
version, which meant that users had barely any time to test on these
upgraded platforms before final release.

I honestly can't see how any of these factors could have been avoided.
Maybe for 5 we could ensure that our release schedule doesn't coincide
with Ubuntu's, but we can't predict Windows/macOS/Fedora/etc release
schedules, so that would only be a small band aid.

Nyall