[Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January

[Volker Hilsheimer]

> On 5 Jan 2021, at 21:18, Max Paperno <max-l at wdg.us> wrote:
> 
> On 1/5/2021 1:02 PM, Adam Light wrote:
>> On Tue, Jan 5, 2021 at 7:56 AM Volker Hilsheimer <volker.hilsheimer at qt.io <mailto:volker.hilsheimer at qt.io>> wrote:
>>    Apart from that: is Qt 5.15.2 really so broken that people can’t use
>>    it without getting more patches?
>> I can't speak to 5.15 as we decided not to upgrade since it's not a real LTS release (we do not believe we are eligible to purchase a commercial license), but the minor fixes that come later in LTS releases (5.9 and 5.12) have often fixed problems our users have reported in our application, particularly on macOS. Due to behavior changes in different Qt minor versions (again, primarily on macOS), we typically change the Qt minor version only when we release a new major version of our application (~every 2-3 years).
>> LTS releases have been critical in our successful use of Qt, and I am not sure what will happen moving forward.
>> Adam
> 
> Hear, hear.  Stuck on 5.12 here.
> 
> Working on OS projects, commercial is not even an option, and resources (e.g. for testing/fixing on every new Qt release) are very limited (read: one person often does everything). E.g. testing one app on 5.14.1 yielded 3 breaking Qt issues which had to be fixed upstream, and mostly didn't make it into .2 either. LTS (after like a .3 or so update) is the only way to go IMHO, the others are for testing/playing.
> 
> I'm so sick of "scheduled releases come hell or high water" in the programming world (in general, not just Qt).  The quality is (usually) crap.  Once upon a time this release quality was called Alpha/Beta/Preview/NFP (not for production).  Qt6 has literally been called as being "primarily" for testing/feedback.  That's a new major release now?  /further rant aborted
> 
> Sorry, I'm only passionate about it because I love what Qt does and I love when it does it well and consistently.  Everyone who's helped make it that way is my hero, thank you!
> 
> -Max


Hi Max and Adam,


What can do better to avoid such regressions from making it into a release, or preferably into the code, in the first place? Nobody, not even the Qt Company management :P *wants* to release crappy quality on time.

What we know about those bugs is that they passed all code reviews, and didn’t get caught by any of the thousands of tests we run for every change on half a dozen platforms. And we know that the only way they were discovered is real users testing real applications against the released version of Qt.

So, what we have is clearly not good enough, but if the last 15 years of writing unit tests etc hasn’t gotten us to a better place, then maybe “more of the same” can’t be the only strategy.

Is your experience that we release stuff “come hell or high water" in spite of severe bugs being reported during beta testing? We do spend a lot of time triaging incoming bug reports, and a severe enough bug can always block a release.

Or do we not discover the issues until the .0 release because few people test the pre-releases? That seems to be supported by the data we have about downloads and general activity in response to pre-releases.


Volker