On Fri, Feb 10, 2017 at 3:59 AM, Tuukka Turunen <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
