Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Lars Knoll]

> On 4 May 2017, at 16:51, Sergio Martins  wrote:
> 
> On 2017-05-04 15:18, Thiago Macieira wrote:
>> Em quinta-feira, 4 de maio de 2017, às 06:58:53 PDT, Konstantin Tokarev
>> escreveu:
>>> But we could have Linux clang configuration with clazy plugin.
>> Why? Clazy is not part of our development philosophy. We should only do that
>> after there's a QUIP explaining which options in Clazy we use (which there
>> isn't).
> 
> Probably the QUIP shouldn't be about clazy /per se/, but about which coding 
> practices we want to enforce via static analysis tooling.
> clazy's current warning set could be used as a starting base for the 
> discussion though, because it exists.

This is getting a bit off topic ;-)

Enforcing certain coding standards is probably a good idea. And we might be 
able to enforce more things in CI once the work on the virtualisation layer is 
done and we can scale up the available hardware.

> 
> But more about that *later*! There's interesting things in the pipeline which 
> KDAB would like to show first.
> 
Looking forward to that :)

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Sergio Martins]

On 2017-05-04 15:18, Thiago Macieira wrote:

Em quinta-feira, 4 de maio de 2017, às 06:58:53 PDT, Konstantin Tokarev
escreveu:

But we could have Linux clang configuration with clazy plugin.


Why? Clazy is not part of our development philosophy. We should only do 
that
after there's a QUIP explaining which options in Clazy we use (which 
there

isn't).


Probably the QUIP shouldn't be about clazy /per se/, but about which 
coding practices we want to enforce via static analysis tooling.
clazy's current warning set could be used as a starting base for the 
discussion though, because it exists.



But more about that *later*! There's interesting things in the pipeline 
which KDAB would like to show first.




Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 07:34:34 PDT, Sergio Martins escreveu:
> On 2017-05-04 14:53, Thiago Macieira wrote:
> > Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet
> > 
> > escreveu:
> >> Clang 4: Do we really need this to be tested with Linux in CI? If yes,
> >> then
> >> which configuration it will be replaced?
> > 
> > I don't think we need to. The macOS builds should be sufficient for
> > almost
> > everything intrinsic to Clang. Those of us who test it on Linux will
> > submit
> > fixes as needed.
> 
> We've introduced bugs in the past that would have been caught
> immediately by clang + Werror if it had been in the CI.
> clang has warnings that gcc doesn't have. Apple Clang is based on older
> clang (which one?), so doesn't have all the nice warnings.

I'm not doubting it has benefits. That's why I build with it on my machine. In 
fact, I build linux-clang more often than macx-clang or win32-msvc.

But Heikki's message implies it's not in the CI, so we're not losing anything 
we had. We're just not adding something we've never had.

> I don't know the cost of adding it to the CI, so I won't comment on the
> cost/benefit relation.

That's exactly the point. The question was: "what should it replace" and I 
don't think we can confidently say it should replace anything.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Sergio Martins]

On 2017-05-04 14:53, Thiago Macieira wrote:
Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet 
escreveu:
Clang 4: Do we really need this to be tested with Linux in CI? If yes, 
then

which configuration it will be replaced?


I don't think we need to. The macOS builds should be sufficient for 
almost
everything intrinsic to Clang. Those of us who test it on Linux will 
submit

fixes as needed.


We've introduced bugs in the past that would have been caught 
immediately by clang + Werror if it had been in the CI.
clang has warnings that gcc doesn't have. Apple Clang is based on older 
clang (which one?), so doesn't have all the nice warnings.



I don't know the cost of adding it to the CI, so I won't comment on the 
cost/benefit relation.




Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 06:58:53 PDT, Konstantin Tokarev 
escreveu:
> But we could have Linux clang configuration with clazy plugin.

Why? Clazy is not part of our development philosophy. We should only do that 
after there's a QUIP explaining which options in Clazy we use (which there 
isn't).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Konstantin Tokarev]

04.05.2017, 16:53, "Thiago Macieira" :
> Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet escreveu:
>>  Clang 4: Do we really need this to be tested with Linux in CI? If yes, then
>>  which configuration it will be replaced?
>
> I don't think we need to. The macOS builds should be sufficient for almost
> everything intrinsic to Clang. Those of us who test it on Linux will submit
> fixes as needed.

But we could have Linux clang configuration with clazy plugin.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 00:23:46 PDT, Heikki Halmet escreveu:
> Clang 4: Do we really need this to be tested with Linux in CI? If yes, then
> which configuration it will be replaced?

I don't think we need to. The macOS builds should be sufficient for almost 
everything intrinsic to Clang. Those of us who test it on Linux will submit 
fixes as needed.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes - SUMMARY

[Heikki Halmet]

Hi,

First of all thank you for all these comments!


There was few changes to the ‘proposal changes list’ and here is the summary:

32-bit iOS: will be dropped from CI and will be no longer supported by Qt
OSX 10.10: will be dropped from CI, but will be supported by Qt
GCC 7: When released it will be tested with some linux distro in CI
Clang 4: Do we really need this to be tested with Linux in CI? If yes, then 
which configuration it will be replaced?



Br
Heikki Halmet






-Original Message-
From: Development 
[mailto:development-bounces+heikki.halmet=qt...@qt-project.org] On Behalf Of 
Tuukka Turunen
Sent: 2. toukokuuta 2017 10:23
To: Jake Petroules <jake.petrou...@qt.io>; Lars Knoll <lars.kn...@qt.io>
Cc: Qt development mailing list <development@qt-project.org>
Subject: Re: [Development] Proposal for Qt 5.10 platforms and configurations 
changes


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" <jake.petrou...@qt.io> wrote:


> On Apr 27, 2017, at 11:28 PM, Lars Knoll <lars.kn...@qt.io> wrote:
> 
> 
>> On 27 Apr 2017, at 16:59, Jake Petroules <jake.petrou...@qt.io> wrote:
>> 
>>> 
>>> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen <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.

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 constitute

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Tuukka Turunen]

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"  wrote:


> On Apr 27, 2017, at 11:28 PM, Lars Knoll  wrote:
> 
> 
>> On 27 Apr 2017, at 16:59, Jake Petroules  wrote:
>> 
>>> 
>>> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen  
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 

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Thiago Macieira]

On Saturday, 29 April 2017 19:14:54 -03 Mat Sutcliffe wrote:
> It also controls whether Q_DECL_CONSTEXPR expands to constexpr or nothing.
> But I don't think that should alter whether or not a function is inline,
> because functions declared with Q_DECL_CONSTEXPR should already be inline
> anyway.

All constexpr functions are by definition inline. The question is whether MSVC 
2017 mangles them especially because of that fact.

With the simple attached testcase, I compiled with MSVC 2017. The resulting 
symbols were:

?normal_inline@Foo@@QEAAHXZ ; Foo::normal_inline
?constexpr_inline@Foo@@QEAAHXZ  ; Foo::constexpr_inline 

The mangling QEAAHXZ expands to:
Q   public
E   __far64 / __ptr64
A   no cv-qualification
A   __cdecl
H   return type: int
X   parameter list: void
Z   throw list: ... [unused, all functions end in Z]

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
class __declspec(dllexport) Foo
{
public:
inline int normal_inline() { return 42; }
constexpr int constexpr_inline() { return 42; }
};
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Mat Sutcliffe]

On 29 April 2017 at 21:31, Thiago Macieira 
wrote:

> On Friday, 28 April 2017 12:50:41 -03 Mat Sutcliffe wrote:
> > tldr: MSVC expects to see linker symbols for inline member functions of
> > exported classes. When such a function is defined within #ifdef
> > Q_COMPILER_foo (being a macro that is defined for 2017 but not 2015) this
> > could mean linker errors. Unknown if this effect has actually been
> observed
> > or is merely theoretical.
>
> Thanks Mat.
>
> If this is the only issue, then it's only a potential issue that will not
> affect us. There's exactly one Q_COMPILER_foo macro that is in 2017 that
> isn't
> in 2015:
> Q_COMPILER_CONSTEXPR
>
> And the totality of its use in public headers, aside from the definition in
> qcompilerdetection.h, is...


It also controls whether Q_DECL_CONSTEXPR expands to constexpr or nothing.
But I don't think that should alter whether or not a function is inline,
because functions declared with Q_DECL_CONSTEXPR should already be inline
anyway.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Thiago Macieira]

On Friday, 28 April 2017 12:50:41 -03 Mat Sutcliffe wrote:
> tldr: MSVC expects to see linker symbols for inline member functions of
> exported classes. When such a function is defined within #ifdef
> Q_COMPILER_foo (being a macro that is defined for 2017 but not 2015) this
> could mean linker errors. Unknown if this effect has actually been observed
> or is merely theoretical.

Thanks Mat.

If this is the only issue, then it's only a potential issue that will not 
affect us. There's exactly one Q_COMPILER_foo macro that is in 2017 that isn't 
in 2015:
Q_COMPILER_CONSTEXPR

And the totality of its use in public headers, aside from the definition in 
qcompilerdetection.h, is:

- qtbase/src/corelib/thread/qbasicatomic.h

#elif defined(Q_COMPILER_ATOMICS) && (defined(Q_COMPILER_CONSTEXPR) || 
defined(Q_OS_QNX))
#  include 

// We only support one fallback: MSVC, because even on version 2015, it lacks 
full constexpr support
#elif defined(Q_CC_MSVC)
#  include 
[...]
#if defined(Q_COMPILER_CONSTEXPR) && defined(Q_COMPILER_DEFAULT_MEMBERS) && 
defined(Q_COMPILER_DELETE_MEMBERS)
#  define QT_BASIC_ATOMIC_HAS_CONSTRUCTORS
#endif

- qtbase/src/corelib/arch/qatomic_cxx11.h

#if defined(Q_COMPILER_CONSTEXPR) && defined(Q_COMPILER_DEFAULT_MEMBERS) && 
defined(Q_COMPILER_DELETE_MEMBERS)
#  define Q_BASIC_ATOMIC_INITIALIZER(a) { a }
#else
#  define Q_BASIC_ATOMIC_INITIALIZER(a) { ATOMIC_VAR_INIT(a) }
#endif

- qtbase/src/corelib/global/qnamespace.h

#if defined(Q_COMPILER_CLASS_ENUM) && defined(Q_COMPILER_CONSTEXPR)
enum class Initialization {
Uninitialized
};
static constexpr Q_DECL_UNUSED Initialization Uninitialized = 
Initialization::Uninitialized;
#else
enum Initialization {
Uninitialized
};
#endif

None of those affect an exported class.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Jake Petroules]

> On Apr 27, 2017, at 11:28 PM, Lars Knoll  wrote:
> 
> 
>> On 27 Apr 2017, at 16:59, Jake Petroules  wrote:
>> 
>>> 
>>> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen  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 

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Jake Petroules]

> On Apr 27, 2017, at 11:54 PM, Shawn Rutledge  wrote:
> 
> 
>> On 27 Apr 2017, at 16:59, Jake Petroules  wrote:
>> 
>> 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).
> 
> Well, the latest iOS versions don’t run on devices of a certain age (and in 
> other cases, you can upgrade but you’d better not, because you’ll regret it) 
> - that’s their way of shaking you down.  But as long as developers can keep 
> enabling continued use of those devices somehow rather than sending them 
> promptly to the shredder as soon as Apple wants you to, I think we should 
> support them in their efforts, or at least not interfere.

Removing 32-bit support from our packages only drops the iPhone 5 from support 
by Qt. The 5s and above are all 64-bit so this has been a long time coming.

I'm all for dropping 32-bit "support" (from the CI). If people REALLY need 
32-bit, they can go compile it themselves.

> 
>> On 27 Apr 2017, at 17:00, Jake Petroules  wrote:
>> 
>>> On Apr 27, 2017, at 7:40 AM, BogDan Vatra  wrote:
>>> 
>>> For Android I'd like to support 64 bit platforms (arm and x86)
>> 
>> They are already supported. Feel free to compile Qt with the appropriate 
>> -arch options. Do you mean you want them in CI and want us to start shipping 
>> binaries for android amd64 and arm64?
>> 
>> I'm not sure there's enough 64-bit devices out there to justify it yet. 
>> Android moves very slow...
> 
> Lollipop came out in 2014.  And there were 64-bit devices available by then.  
> So I suspect the majority of new devices are 64-bit by now.
> 
> If _users_ are slow to upgrade their devices, that’s really good on them, not 
> going along with the planned obsolescence nonsense which is purely harmful: 
> to your wallet, to the environment, to the sense of guilt that you feel when 
> you do the wrong thing, and increasing inequality in the economy.  Apple gets 
> a black mark in my book for trying so hard to remove that choice.
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Thiago Macieira]

On Friday, 28 April 2017 09:51:58 -03 Benjamin TERRIER wrote:
> 2017-04-28 14:23 GMT+02:00 Thiago Macieira :
> > On Friday, 28 April 2017 03:56:22 -03 Jani Heikkinen wrote:
> >> Yes, MSVC 2017 is already supported in Qt 5.9 and we are trying to get
> >> pre-built binaries available before final release;  let's see if we can
> >> make it happen
> > 
> > I remember a discussion about whether we needed MSVC 2017 binaries in the
> > first place, since they're binary compatible with MSVC 2015 and we don't
> > have "win32-msvc2015" anymore, which concluded we did. I don't remember
> > the reason.
> > 
> > Does anyone?
> 
> I recall this (it's from you):
> > We can't drop it from the CI. I don't think we can drop it from the build
> > packages either, since usually you compile with the oldest you plan to
> > use. So if you're correct and VS2017 is binary-compatible, then we are
> > already providing the packages for VS2017.
> 
> http://lists.qt-project.org/pipermail/development/2017-February/028768.html

That's the opposite: that's the argument of why we should not need a VS2017 
binary.

I'm asking if anyone remembers the argument why we should.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Mat Sutcliffe]

On 28 April 2017 at 13:51, Benjamin TERRIER  wrote:

> 2017-04-28 14:23 GMT+02:00 Thiago Macieira :
> > On Friday, 28 April 2017 03:56:22 -03 Jani Heikkinen wrote:
> >> Yes, MSVC 2017 is already supported in Qt 5.9 and we are trying to get
> >> pre-built binaries available before final release;  let's see if we can
> >> make it happen
> >
> > I remember a discussion about whether we needed MSVC 2017 binaries in
> the first
> > place, since they're binary compatible with MSVC 2015 and we don't have
> > "win32-msvc2015" anymore, which concluded we did. I don't remember the
> reason.
> >
> > Does anyone?
>
> I recall this


Also these:
http://lists.qt-project.org/pipermail/development/2017-March/029200.html
[Marc]
http://lists.qt-project.org/pipermail/development/2017-March/029202.html
[Thiago]

tldr: MSVC expects to see linker symbols for inline member functions of
exported classes. When such a function is defined within #ifdef
Q_COMPILER_foo (being a macro that is defined for 2017 but not 2015) this
could mean linker errors. Unknown if this effect has actually been observed
or is merely theoretical.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Benjamin TERRIER]

2017-04-28 14:23 GMT+02:00 Thiago Macieira :
> On Friday, 28 April 2017 03:56:22 -03 Jani Heikkinen wrote:
>> Yes, MSVC 2017 is already supported in Qt 5.9 and we are trying to get
>> pre-built binaries available before final release;  let's see if we can
>> make it happen
>
> I remember a discussion about whether we needed MSVC 2017 binaries in the 
> first
> place, since they're binary compatible with MSVC 2015 and we don't have
> "win32-msvc2015" anymore, which concluded we did. I don't remember the reason.
>
> Does anyone?

I recall this (it's from you):

> We can't drop it from the CI. I don't think we can drop it from the build
> packages either, since usually you compile with the oldest you plan to use. So
> if you're correct and VS2017 is binary-compatible, then we are already
> providing the packages for VS2017.

http://lists.qt-project.org/pipermail/development/2017-February/028768.html

BR,

Benjamin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Thiago Macieira]

On Friday, 28 April 2017 03:56:22 -03 Jani Heikkinen wrote:
> Yes, MSVC 2017 is already supported in Qt 5.9 and we are trying to get
> pre-built binaries available before final release;  let's see if we can
> make it happen

I remember a discussion about whether we needed MSVC 2017 binaries in the first 
place, since they're binary compatible with MSVC 2015 and we don't have 
"win32-msvc2015" anymore, which concluded we did. I don't remember the reason.

Does anyone?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Edward Welbourne]

>> 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

Lars Knoll (28 April 2017 08:28):
> 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.

It remains that the distinction between "if you get it fixed, we'll take
it in" and "we don't want our code complicated with fixes for that".  We
do need to make clear which platforms are in the former (Tier 2) state
and which in the latter (Unsupported) - if only so that reviewers know
to be consistent,

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Jani Heikkinen]

Hi,
Yes, MSVC 2017 is already supported in Qt 5.9 and we are trying to get 
pre-built binaries available before final release;  let's see if we can make it 
happen

br,
jani

From: Development <development-bounces+jani.heikkinen=qt...@qt-project.org> on 
behalf of Wolfgang Baron <wolfgang.ba...@gmx.net>
Sent: Friday, April 28, 2017 12:03 AM
To: Liang Qi
Cc: development@qt-project.org
Subject: Re: [Development] Proposal for Qt 5.10 platforms and configurations 
changes

HI,

Am 27.04.2017 um 22:54 schrieb Liang Qi:
On 27 April 2017 at 22:50, Wolfgang Baron 
<wolfgang.ba...@gmx.net<mailto:wolfgang.ba...@gmx.net>> wrote:
Hi,

I would like to see msvc_2017 support on the Windows plattform for any version 
as soon as possible.

That will happen soon in 5.9, please follow up 
https://codereview.qt-project.org/#/c/191981/ and etc.

Thanks, I didn't see that and don't see a "msvc2017 64-bit" for "Qt 5.9 Beta2" 
in the online installer, so I was afraid it would not be in the release either. 
Good to hear it will be there for the release!

Kind regards,

Wolfgang Baron
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Shawn Rutledge]

> On 27 Apr 2017, at 16:59, Jake Petroules  wrote:
> 
> 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).

Well, the latest iOS versions don’t run on devices of a certain age (and in 
other cases, you can upgrade but you’d better not, because you’ll regret it) - 
that’s their way of shaking you down.  But as long as developers can keep 
enabling continued use of those devices somehow rather than sending them 
promptly to the shredder as soon as Apple wants you to, I think we should 
support them in their efforts, or at least not interfere.

> On 27 Apr 2017, at 17:00, Jake Petroules  wrote:
> 
>> On Apr 27, 2017, at 7:40 AM, BogDan Vatra  wrote:
>> 
>> For Android I'd like to support 64 bit platforms (arm and x86)
> 
> They are already supported. Feel free to compile Qt with the appropriate 
> -arch options. Do you mean you want them in CI and want us to start shipping 
> binaries for android amd64 and arm64?
> 
> I'm not sure there's enough 64-bit devices out there to justify it yet. 
> Android moves very slow...

Lollipop came out in 2014.  And there were 64-bit devices available by then.  
So I suspect the majority of new devices are 64-bit by now.

If _users_ are slow to upgrade their devices, that’s really good on them, not 
going along with the planned obsolescence nonsense which is purely harmful: to 
your wallet, to the environment, to the sense of guilt that you feel when you 
do the wrong thing, and increasing inequality in the economy.  Apple gets a 
black mark in my book for trying so hard to remove that choice.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Simon Hausmann]

Hi,

Exactly cutting down the time it takes for the CI to complete a build of all of 
Qt is one of the motivation factors. And note how in dev (and bus 5.10) we are 
spending extra time building for WatchOS and TvOS, so it would seem like a 
trade to me ;)

Simon

On 28. Apr 2017, at 08:28, Lars Knoll 
> wrote:


On 27 Apr 2017, at 16:59, Jake Petroules 
> wrote:


On Apr 27, 2017, at 7:07 AM, Tuukka Turunen 
> 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 

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Bogdan Vatra]

Hi Jake,

On joi, 27 aprilie 2017 15:00:58 EEST Jake Petroules wrote:
> > On Apr 27, 2017, at 7:40 AM, BogDan Vatra  wrote:
> > 
> > For Android I'd like to support 64 bit platforms (arm and x86)
> 
> 
> They are already supported. Feel free to compile Qt with the appropriate
> -arch options. 
I know about that option, because, well, I implement it :).

> Do you mean you want them in CI and want us to start
> shipping binaries for android amd64 and arm64?
Yes, this is what I mean!

> I'm not sure there's enough 64-bit devices out there to justify it yet.
> Android moves very slow...
My hunch is that in 2016 there were shipped more Android arm64 devices than 
iOS ones ;-).

x86_64 bins will be used only for chromebooks, though it seems google is 
moving way from x86 also on chromebooks, so x86_64 are low priority.

Cheers,
BogDan.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Lars Knoll]

On 27 Apr 2017, at 16:59, Jake Petroules 
> wrote:


On Apr 27, 2017, at 7:07 AM, Tuukka Turunen 
> 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 

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Giuseppe D'Angelo]

Il 27/04/2017 23:37, Thiago Macieira ha scritto:
> Because if you mean the former, it's already supported in 5.8.

But not in 5.8.0. So, effectively, in no released 5.8 version.

[grumbles]

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Thiago Macieira]

On Thursday, 27 April 2017 18:03:32 -03 Wolfgang Baron wrote:
> Thanks, I didn't see that and don't see a "msvc2017 64-bit" for "Qt 5.9
> Beta2" in the online installer, so I was afraid it would not be in the
> release either. Good to hear it will be there for the release!

There's no need. You can use the MSVC 2015 installer.:

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Thiago Macieira]

On Thursday, 27 April 2017 17:50:08 -03 Wolfgang Baron wrote:
> Hi,
> 
> I would like to see msvc_2017 support on the Windows plattform for any
> version as soon as possible.

Do you mean "support" as in "it works" or as in "it's tested in the CI".

Because if you mean the former, it's already supported in 5.8.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Wolfgang Baron]

HI,


Am 27.04.2017 um 22:54 schrieb Liang Qi:
On 27 April 2017 at 22:50, Wolfgang Baron > wrote:


Hi,

I would like to see msvc_2017 support on the Windows plattform for
any version as soon as possible.

That will happen soon in 5.9, please follow up 
https://codereview.qt-project.org/#/c/191981/ and etc.


Thanks, I didn't see that and don't see a "msvc2017 64-bit" for "Qt 5.9 
Beta2" in the online installer, so I was afraid it would not be in the 
release either. Good to hear it will be there for the release!


Kind regards,

Wolfgang Baron
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Liang Qi]

On 27 April 2017 at 22:50, Wolfgang Baron  wrote:

> Hi,
>
> I would like to see msvc_2017 support on the Windows plattform for any
> version as soon as possible.


That will happen soon in 5.9, please follow up
https://codereview.qt-project.org/#/c/191981/ and etc.

Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Wolfgang Baron]

Hi,

I would like to see msvc_2017 support on the Windows plattform for any 
version as soon as possible.


Best regards,

Wolfgang Baron
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Thiago Macieira]

On Thursday, 27 April 2017 09:02:33 -03 Ville Voutilainen wrote:
> That's because GCC 7 hasn't been released yet, but it will be soon,
> and then it will be in almost every linux distro as a system
> compiler before we ship Qt 5.10, so I think it would be quite wise to
> have it in CI as soon as possible.

If not "before we ship 5.10", it will be the compiler of choice for Linux 
distros in 2018, which is when 5.10 is supposed to be used.

That said, we will be testing ourselves (I've already updated my openSUSE 
Tumbleweed for it), so it's not like it will be broken. I've also been 
building Qt 5.9 with Clang 5.0 (trunk).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Jake Petroules]

> On Apr 27, 2017, at 7:40 AM, BogDan Vatra  wrote:
> 
> For Android I'd like to support 64 bit platforms (arm and x86)

They are already supported. Feel free to compile Qt with the appropriate -arch 
options. Do you mean you want them in CI and want us to start shipping binaries 
for android amd64 and arm64?

I'm not sure there's enough 64-bit devices out there to justify it yet. Android 
moves very slow...

> 
> BogDan.
> 
> On April 27, 2017 12:29:08 PM GMT+03:00, Heikki Halmet  
> 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)
> 
> macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available)
> 
> 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.
> 
>  
> 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
> 
> Phone: +358408672112
> 
> www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject 
> Facebook: www.facebook.com/qt
> 
>  
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my 
> brevity.___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Jake Petroules]

> On Apr 27, 2017, at 7:07 AM, Tuukka Turunen  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.

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...

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

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).

> - 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" 
>  jake.petrou...@qt.io> wrote:
> 
> 
>> On Apr 27, 2017, at 2:29 AM, Heikki Halmet  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 

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[BogDan Vatra]

For Android I'd like to support 64 bit platforms (arm and x86)

BogDan.

On April 27, 2017 12:29:08 PM GMT+03:00, Heikki Halmet  
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)
>
>macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available)
>
>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.
>
>
>
>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
>Phone: +358408672112
>www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter:
>@qtproject, @Qtproject Facebook:
>www.facebook.com/qt

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[James McDonnell]

The mkspecs are there.  https://codereview.qt-project.org/#/c/192579/ is
needed to make them work (again).


On 2017-04-27, 8:07 AM, "Development on behalf of Stottlemyer, Brett
(B.S.)"  wrote:

>> Please refer to Qt 5.9 Supported platforms ->
>>http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html
>
>That page has the following for QNX: ³QNX 6.6.0, 7.0 (armv7le and x86)²
>
>As QNX 7.0 includes 64-bit support, are aarch64le and x86_64 supported on
>5.9?  If not, can they be added for 5.10?
>
>Regards,
>Brett
>
>___
>Development mailing list
>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

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Tuukka Turunen]

Correcting myself: Drop ARMv7 and ARMv7s support for iOS, meaning we only 
support 64bit iOS devices from Qt 5.10 onwards.

Yours,

Tuukka

From: Development <development-bounces+tuukka.turunen=qt...@qt-project.org> on 
behalf of Tuukka Turunen <tuukka.turu...@qt.io>
Sent: Thursday, April 27, 2017 4:07:48 PM
To: Jake Petroules; Heikki Halmet; development@qt-project.org
Subject: Re: [Development] Proposal for Qt 5.10 platforms and configurations 
changes


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
- Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus 
supporting three latest ones means dropping one)

Yours,

Tuukka

On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" 
<development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of 
jake.petrou...@qt.io> wrote:


> On Apr 27, 2017, at 2:29 AM, Heikki Halmet <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
> Phone: +358408672112
> 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
> http://lists.qt-project.org/mailman/listinfo/development

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

___
Development mailing list
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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Tuukka Turunen]

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
- Drop macOS 10.10 support (we are adding 10.13 or whatever, and thus 
supporting three latest ones means dropping one)

Yours,

Tuukka

On 27/04/2017, 13.11, "Development on behalf of Jake Petroules" 
 wrote:


> On Apr 27, 2017, at 2:29 AM, Heikki Halmet  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
> Phone: +358408672112
> www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject 
Facebook: www.facebook.com/qt
>  
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

___
Development mailing list
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

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Stottlemyer, Brett (B.S.)]

> Please refer to Qt 5.9 Supported platforms -> 
> http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html

That page has the following for QNX: “QNX 6.6.0, 7.0 (armv7le and x86)” 

As QNX 7.0 includes 64-bit support, are aarch64le and x86_64 supported on 5.9?  
If not, can they be added for 5.10?

Regards,
Brett

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Ville Voutilainen]

On 27 April 2017 at 14:58, Shawn Rutledge  wrote:
> Giuseppe was asking on IRC for GCC 7 and Clang 4.  Which are quite bleeding 
> edge for almost all distros at this point, I suppose; Arch recently got Clang 
> 4 but not GCC 7 yet.


That's because GCC 7 hasn't been released yet, but it will be soon,
and then it will be in almost every linux distro as a system
compiler before we ship Qt 5.10, so I think it would be quite wise to
have it in CI as soon as possible.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Shawn Rutledge]

> On 27 Apr 2017, at 11:29, Heikki Halmet  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)
> macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available)
> 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.
>  
> 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.

Giuseppe was asking on IRC for GCC 7 and Clang 4.  Which are quite bleeding 
edge for almost all distros at this point, I suppose; Arch recently got Clang 4 
but not GCC 7 yet.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Jake Petroules]

> On Apr 27, 2017, at 2:29 AM, Heikki Halmet  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
> Phone: +358408672112
> www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject 
> Facebook: www.facebook.com/qt
>  
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development