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

[Gunnar Roth]

> 
> We can't provide binaries because, with Visual Studio, the different releases 
> are not binary-compatible with each other. If we built our releases with the 
> RC, it may not run with your application that you compiled with the final. And 
> since we promise to keep our compatibility forwards and backwards inside a 
> minor series, we don't like to update the MSVC version so you can just drop in 
> the new release and not have to rebuild everything.
vcblog says: " Specifically, VS 2015 and VS “15” will have the same major compiler version (19) and their STLs will be binary-compatible, and this compatible compiler and STL will remain available throughout the lifecycle of VS “15”.  This implies that the STL’s DLL will continue to be named msvcp140.dll.  (At some point in the future, we expect to have a compiler version 20 and a binary-incompatible STL again.)"

> 
> Maybe we ought to revisit that.
> 
yes.

> The next problem is the load on the build servers and on the people doing the 
> testing that the generated binaries actually work. See the discussion we had a 
> couple of months ago on what we'd release for 5.8 and 5.9. We need to keep the 
> number of binaries to a constant number. So adding MSVC 2017 would mean 
> dropping something.
yes dropping vs2015 build as using the latest 19.xx compiler will be binary compatible to vs2015 code.


> But we did make MSVC 2017 work with 5.8. We solved all build issues we could 
> find.
Well sadly that does not include 5.8.0, so now users have to wait at least until may to get a vs2017 ( which will be released on March 9th).

> 
>> 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".
> 
> That's unlikely to happen.
> 
> How about asking Microsoft to follow up on their promise of keeping binary 
> compatibility instead? That way, the binaries built with MSVC 2017 will work 
> with 2018 and we don't have to rebuild.

How about Qt supports the binary compatibility bewegen cl19.00 and cl cl19.xx instead on making a win32-msvc2017?
mkspec should be based on the cl major version , instead of the IDE year. QtCreator complains when you try to use a qt with 2017 mkspec and a 2015 compiler set.

Regards,
Gunnar Roth



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170212/5147e923/attachment.html>