[Releasing] [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Torben Dannhauer]

Charley, 

Thanks for the input.

I totally agree with you. I proposed some years ago an Preview/RC based
adoption of Qt, but this was refused.

I think Qt need to adopt as early as possible to new VS releases to be ready
once it is released as final.

"*way* to late" is eactly the wording I would use to describe the current
adoption speed.

Best regards,
Torben


-----Ursprüngliche Nachricht-----
Von: Releasing
[mailto:releasing-bounces+torben=dannhauer.info at qt-project.org] Im Auftrag
von charleyb123 .
Gesendet: Samstag, 11. Februar 2017 15:08
An: Tuukka Turunen <tuukka.turunen at qt.io>
Cc: development at qt-project.org; releasing at qt-project.org
Betreff: Re: [Releasing] [Development] Focusing bug fixes to 5.9 branch and
patch releases during H1/17

On Fri, Feb 10, 2017 at 3:59 AM, Tuukka Turunen <tuukka.turunen at qt.io>
wrote:
> Short summary: The Qt Company has decided to focus development effort 
> to 5.9 and dev branches in order to reach the planned timeline for Qt 
> 5.9 release and make improvements in the CI system. <snip>,

> In the CI system side we have major improvements happening during this
year.
> We will be purchasing more blades and other HW during H1/17, which 
> will add capacity, so we will be able to run more parallel 
> integrations. <snip>

Perhaps related, I think it might be a good idea to target more closely new
compiler releases from Microsoft.

In the past several years they have shifted to an early-and-frequent update
model, and organizations are adapting to more aggressively take advantage of
new C++ language features, and to target platform technology changes.  For
example MSVC++2017 (version 15) was previewed in March-2016; has had three
major updates; went to RC in Nov-2016; and is announced for launch in
March-2017 (see:
http://www.zdnet.com/article/microsoft-to-release-visual-studio-2017-on-marc
h-7/).

That tool chain was actually at very high quality since its launch a year
ago (this is their new release model), and I'm aware of companies that have
relied on that version for commercial development since its preview access.

IMHO, not providing binaries for that platform is a hindrance to Qt
adoption.  Intel provides chips to OEMs before launch, and companies
regularly provide pre-release technology access to allow OEMs time to
integrate with their products, and I'm suggesting Qt should similarly
support this type of early-access (we can call it "pre-release" access if we
want).

Yes, developers can build their own Qt binaries; but this is a non-trivial
point of friction, and you need to install Python, and become familiar with
config, etc.  The "experts" have success here, but we continue to see email
threads on stumped non-experts unable to get working Qt binaries.  If we
want friction-less Qt adoption (perhaps even for casual and accidental
developer exposure), we should just provide the binaries.

Yes, I'm very aware that some companies are on the slow-stable upgrade model
and need long support for older compilers.  I'm talking about another market
where requirements and competitive advantage demand access to new tooling,
(consistent with the fast pace of web technology advances and the need for
security patches and updates).

Under this proposal, Qt binaries would be available for MSVC++2018 when it
is previewed, or at least most certainly when it goes to RC.
Waiting for it to deploy is *way* too late, as the new Microsoft release
model suggests that developers have been integrating the compiler into their
tooling for a year before Qt "shows up".

--charley
_______________________________________________
Releasing mailing list
Releasing at qt-project.org
http://lists.qt-project.org/mailman/listinfo/releasing