[Releasing] [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Torben Dannhauer]

Zitat von Roland Winklmeier <roland.m.winklmeier at gmail.com>:

> 2017-02-15 12:52 GMT+01:00 Shawn Rutledge <Shawn.Rutledge at qt.io>:
>
>>
>> > On 15 Feb 2017, at 11:11, Marc Mutz <marc.mutz at kdab.com> wrote:
>> >
>> > On Wednesday 15 February 2017 10:36:33 Sean Harmer wrote:
>> >> First of all, apologies for not being able to make the release meeting
>> >> yesterday. I was in a workshop all day.
>> >>
>> >> For the record I think skipping 5.8.1 is a big mistake. I would much
>> rather
>> >> delay 5.9 by a few weeks and have a 5.8.1 release out than skip it and
>> try
>> >> for a quick 5.9.0.
>> >
>> > Amen.
>> >
>> > I would like to add that this decision, made behind closed doors, does
>> not
>> > match well with Qt-as-an-open-governance-project. In particular, it
>> feels like
>> > we OSS contributors are being held hostage here. If you close the 5.8 CI,
>> > anything we can do, incl. following the dictate of TQC to focus on 5.9,
>> will
>> > hurt Qt users one way or another. Either we fragment Qt by releasing a
>> 5.8.1
>> > without TQC backing or we leave users hanging in the air for extended
>> periods
>> > of time without the ability for bugfixes. Both are unacceptable, IMHO.
>>
>> There are a lot of potential bug fixes.  Skipping 5.8.1 might pull some
>> users into upgrading to 5.9 sooner than they might otherwise, which is good
>> from one side, but the ones who are afraid of new features and new
>> regressions will resist.  So I think it’s a mistake because of those
>> people…
>>
>
> Speaking for myself, I also think, skipping 5.8.1 is a mistake. We just
> upgraded our project from 5.6 to 5.8 and realized that it had several
> regressions. For example we are using a QNetworkAccessManager and for
> random reasons it always switches to NotAccessible after some minutes. No
> recovery possible except restarting the application. I wonder why nobody
> else got affected by this. I _think_ the cause was QTBUG-51543, even though
> I never finally understood whats going on. In any case, the fix for this
> bug went into 5.8.1, which now won't get released. For me this is very
> frustrating, since we counted our next milestone on an early 5.8.1 release.
> Now I would have to wait for 5.9.0 which is planned end of May if
> everything goes smooth. Even then, there is no guarantee that there is no
> new regression which would require 5.9.1 release.
> I also can't produce custom builds, since I never managed to create a
> custom offline installer for my team members (we are are non profil OSS
> group without many infrastructure and resources). I do regular builds of Qt
> itself, but the rest is out of my capabilities.
>
> In summary, for me it is very unfortunate that I have to delay our
> milestone minimum until June if everything goes well.


+1

I think, for many quality focused software projects, skipping patch  
releases in Qt is a pain.

I would even go further: I recommend to establish guidelines how many  
patch releases should be published (I think at minimum 1, better 2). I  
would give them absolute priority over new minor (or even major)  
releases. If there are shortages in CI , CPU or Disk power, whis  
should primary affeect new releases, not patch releases.
This would
a) support Qt not bo become one of the thousand feature rich but  
unstable and buggy software frameworks/projects
b) taking pressure on fixing this basic shortages

If I had to decide between new features and bugfixed/mature code - I  
would go for mature code.

just my 2 cents,
Torben