Hi,
While I do agree that having a platform in CI and supporting it for those who
have purchased support are not 1:1, in case of dropping the 32-bit iOS from CI
for Qt 5.10 it also means that this configuration should no longer be used and
not be supported. I do not see much problems with that as we continue to
support 32 bit iOS for earlier platforms (until Apple drops it) and the 32 bit
iOS devices are already quite old.
Yours,
Tuukka
On 28/04/2017, 19.58, "Jake Petroules" <[email protected]> wrote:
> On Apr 27, 2017, at 11:28 PM, Lars Knoll <[email protected]> wrote:
>
>
>> On 27 Apr 2017, at 16:59, Jake Petroules <[email protected]> wrote:
>>
>>>
>>> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen <[email protected]>
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"
<[email protected] on behalf of
[email protected]> wrote:
>>>
>>>
>>>> On Apr 27, 2017, at 2:29 AM, Heikki Halmet <[email protected]> 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: [email protected]
>>>> Phone: +358408672112
>>>> www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject,
@Qtproject Facebook: www.facebook.com/qt
>>>>
>>>> _______________________________________________
>>>> Development mailing list
>>>> [email protected]
>>>> http://lists.qt-project.org/mailman/listinfo/development
>>>
>>> --
>>> Jake Petroules - [email protected]
>>> The Qt Company - Silicon Valley
>>> Qbs build tool evangelist - qbs.io
>>>
>>> _______________________________________________
>>> Development mailing list
>>> [email protected]
>>> http://lists.qt-project.org/mailman/listinfo/development
>>>
>>>
>>
>> --
>> Jake Petroules - [email protected]
>> The Qt Company - Silicon Valley
>> Qbs build tool evangelist - qbs.io
>>
>> _______________________________________________
>> Development mailing list
>> [email protected]
>> http://lists.qt-project.org/mailman/listinfo/development
>
--
Jake Petroules - [email protected]
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
