[Development] Proposal for Qt 5.10 platforms and configurations changes

Fri Apr 28 18:58:32 CEST 2017

> On Apr 27, 2017, at 11:28 PM, Lars Knoll <lars.knoll at qt.io> wrote:
> 
> 
>> On 27 Apr 2017, at 16:59, Jake Petroules <Jake.Petroules at qt.io> wrote:
>> 
>>> 
>>> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen <tuukka.turunen at qt.io> wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> Related to the Apple platforms, could we consider the following for Qt 5.10:
>>> - Drop the older iPhone support by removing ARMv7 from iOS (http://dorianroy.com/blog/wp-content/uploads/2016/09/iOS_Support_Matrix_v4.2.pdf)
>>> - Consider also dropping ARMv7s support, which would allow dropping i386 simulator support
>> 
>> I really don't like how we use the term "support" in these emails because it's rather misleading. We use it to mean "tested in CI", whereas I (and most of the world, as far as I can tell) read it as "the code exists and is functional". "Removing support" to me means actively removing the code which makes something functional.
> 
> Agree, there is a difference between the two. 
> 
> What I think we should however do for 5.10 is remove 32bit support for iOS from CI and our binary packages. And that means that things will be untested on 32bit iOS, and thus is likely to break at some point.

I think 32-bit support on iOS is kind of unlikely to break accidentally, but I agree we should remove it from our binary packages. The iPhone 5 is dead.

>> 
>> As an Open Source project, we need to keep in mind that dropping first party "support" for something means little to nothing unless we actually delete the associated code as well and refuse patches to re-add it, because people can always build their own copy of Qt, and commercial support will obviously still answer queries for most definitions of "unsupported", making the term "unsupported" a little meaningless. Perhaps we can start using the term "tier 1 support" as a synonym for what we actually mean by "support", in order to be more clear? I really liked the notion of tiered support that we used to have but it seems to have gone missing…
> 
> For the commercial version, it’s to a large extent up to TQtC to define the support offering. The open source project anyway does not offer any official support for the Qt versions released. All you can do is ask on the mailing lists or file a bug report and hope for the best. Or of course sit down, fix it yourself and submit a patch :)

My point was that if a commercial customer goes to support with a bug in a 32-bit build of Qt for iOS, support won't say "we do not support that, go away". They will fix the problem, regardless of the fact that it isn't part of a reference configuration.

If a customer sets the minimum deployment target of Qt for iOS to 5.0 and then goes to support saying Qt doesn't work, support WILL tell them "we do not support that (because we deliberately broke it), we can't help you and you'll have to talk to Services and pay money if you want it working that badly".

That's the real-world outcome, which is why I don't like using the term "supported" as a synonym for "is a reference configuration in CI".

A reference configuration in CI always constitutes something that is supported. However, something that's supported is not necessarily a reference configuration in CI. We should make this clear to our users by not using the term "supported" in a misleading way.

> 
>> 
>> Something like the following seems nice:
>> Tier 1 - the most rigorously tested configurations, tested in CI
>> Tier 2 - we actively try to make it work but it's a lower priority; will make and accept patches and provide support but isn't tested in CI
>> Unsupported - we remove code that makes the functionality work; will refuse any related patches, commercial support refers queries to a separate (paid) business engagement
> 
> I’m ok to describe things in tiers, as that’s what we have in practice. We don’t test e.g. FreeBSD in CI, but we will accept patches if something’s broken on that platform and someone cares enough to fix it. Same would be true for 32bit iOS in 5.10 then. But the only thing the Qt project will be able to give some guarantees for are the configurations tested in CI. 
>> 
>> Anyways, iOS 11 will likely drop support for 32-bit applications entirely (i.e. they will not launch because 32-bit system libs will be GONE). So I agree we should stop shipping 32-bit slices in our binary distributions of Qt for iOS. We should not deliberately break 32-bit support though (and it's hard to do this accidentally anyways).
> 
> Dropping it has other benefits. Currently iOS is on the critical path in the CI system for qt5.git integrations and thus package creation. Dropping 32bit support going to significantly cut down on iOS compile times, and should thus lead to faster turn around times for package creation.
> 
> Lars
> 
>> 
>>> - Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus supporting three latest ones means dropping one)
>> 
>> Well, the plan is to keep 10.10 supported in 5.10, because we've dropped a macOS release with every release of Qt since 5.6 on, and we have to slow down since Apple's release cadence is annual and ours is bi-annual, or we will end up supporting a negative number of OSes eventually :)
>> 
>> Current list is:
>> - Qt 5.6 - supports macOS 10.7 and up
>> - Qt 5.7 - supports macOS 10.8 and up
>> - Qt 5.8 - supports macOS 10.9 and up
>> - Qt 5.9 - supports macOS 10.10 and up
>> 
>> Planned:
>> - Qt 5.10 - supports macOS 10.10 and up, deprecates macOS 10.10
>> - Qt 5.11 - supports macOS 10.11 and up
>> 
>> By the way, "supported" here means we set the compiler and linker flag stating the minimum version. We actually REMOVE the code for older versions. "Supported" is not synonymous with "tested in CI", and not being tested in CI does not imply "unsupported".
>> 
>> If the quality of our 10.10 support suffers because it is not tested in the CI, then that's that. It would follow well with our usual practice of deprecating the earliest platform one release before removing it outright.
>> 
>> But it will still be "supported" as a deployment platform. I agree that we can remove it from the CI and maybe mark it as a deployment-only platform. (so 10.11 SDK is required, and deploys to 10.10)
>> 
>>> 
>>> Yours,
>>> 
>>> Tuukka
>>> 
>>> On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" <development-bounces+tuukka.turunen=qt.io at qt-project.org on behalf of Jake.Petroules at qt.io> wrote:
>>> 
>>> 
>>>> On Apr 27, 2017, at 2:29 AM, Heikki Halmet <heikki.halmet at qt.io> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Below we have proposal for changes in supported platforms and configurations from Qt 5.9 to 5.10.
>>>> Please comment if the proposal is insufficient or the changes are unacceptable somehow.
>>>> 
>>>> Please refer to Qt 5.9 Supported platforms -> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html
>>>> 
>>>> LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10:
>>>> RHEL 7.2 -> RHEL 7.3 (Any benefits?)
>>>> OpenSUSE 42.1 -> OpenSUSE 42.2
>>>> Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI)
>>>> macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available)
>>> 
>>>   Apple does not ever release updates to older release series, so since 8.3 already exists, this is guaranteed to remain 8.2.1.
>>> 
>>>> macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available)
>>> 
>>>   8.3.2, please.
>>> 
>>>> Windows 7 MinGW 5.3.0 -> MinGW 6.3.0 
>>>> Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3
>>>> INTEGRITY GHS 2016.5.4 -> 2017.1.x 
>>>> Support for Android 8 (if available on time)
>>>> iOS 11 support (if available on time. Current rumors -> september)
>>>> 
>>>> MacOS 10.13 will be released September 2017 hopefully. Feature Freeze for 5.10 is at the beginning of August.
>>>> This means that we can only use Preview release of 10.13 for testing before final official release is out.
>>>> That can cause situation that we don’t have enough time to get 10.13 in before 5.10 release so we can’t give guarantees that 10.13 will be supported in 5.10.
>>> 
>>>   How do you know it won't be called macOS 11? ;)
>>> 
>>>   The purpose of the preview release *IS* to use it for testing so that you can say your product supports the final version (according to Apple). We should provision a VM for the first developer preview and update it throughout the beta cycle until the final release. So this should not be a problem for us with FF in August unless Qt 5.10 releases before macOS Next does.
>>> 
>>>   Just for the record: make sure not to drop CI for macOS 10.10 - that version is still supported in Qt 5.10. Tentative plan for 5.11 would be to drop 10.10 support.
>>> 
>>>> 
>>>> NOTE! We will commit to wanted platform and software changes as long as those are available straight after 5.9 release is out in the end of the May.
>>>> With all others we'll do the best we can but we can't commit that those will be supported in 5.10.
>>>> 
>>>> 
>>>> 
>>>> Best regards
>>>> Heikki Halmet
>>>> 
>>>> The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland
>>>> Email: heikki.halmet at qt.io
>>>> Phone: +358408672112
>>>> www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt
>>>> 
>>>> _______________________________________________
>>>> Development mailing list
>>>> Development at qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/development
>>> 
>>>   -- 
>>>   Jake Petroules - jake.petroules at qt.io
>>>   The Qt Company - Silicon Valley
>>>   Qbs build tool evangelist - qbs.io
>>> 
>>>   _______________________________________________
>>>   Development mailing list
>>>   Development at qt-project.org
>>>   http://lists.qt-project.org/mailman/listinfo/development
>>> 
>>> 
>> 
>> -- 
>> Jake Petroules - jake.petroules at qt.io
>> The Qt Company - Silicon Valley
>> Qbs build tool evangelist - qbs.io
>> 
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 

-- 
Jake Petroules - jake.petroules at qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io