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

[charleyb123 .]

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