On 27 Apr 2017, at 16:59, Jake Petroules <jake.petrou...@qt.io<mailto:jake.petrou...@qt.io>> wrote:
On Apr 27, 2017, at 7:07 AM, Tuukka Turunen <tuukka.turu...@qt.io<mailto:tuukka.turu...@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. 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 :) 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...@qt-project.org<mailto:development-bounces+tuukka.turunen=qt...@qt-project.org> on behalf of jake.petrou...@qt.io<mailto:jake.petrou...@qt.io>> wrote: On Apr 27, 2017, at 2:29 AM, Heikki Halmet <heikki.hal...@qt.io<mailto:heikki.hal...@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.hal...@qt.io<mailto:heikki.hal...@qt.io> Phone: +358408672112 www.qt.io<http://www.qt.io> | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt<http://www.facebook.com/qt> _______________________________________________ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io<http://qbs.io> _______________________________________________ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petrou...@qt.io<mailto:jake.petrou...@qt.io> The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io<http://qbs.io/> _______________________________________________ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
