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:[email protected]] Im Auftrag von charleyb123 . Gesendet: Samstag, 11. Februar 2017 15:08 An: Tuukka Turunen <[email protected]> Cc: [email protected]; [email protected] 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 <[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-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 [email protected] http://lists.qt-project.org/mailman/listinfo/releasing _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
