Re: [Boost-build] MSVC toolset versions on VS2017

Subject: Re: [Boost-build] MSVC toolset versions on VS2017
From: Andrew Pardoe (Andrew.Pardoe_at_[hidden])
Date: 2017-11-20 15:14:26

>-----Original Message-----
>From: Boost-build [mailto:boost-build-bounces_at_[hidden]] On Behalf Of Daniel James via Boost-build
>Sent: Monday, November 20, 2017 5:09 AM
>To: Boost.Build developer's and user's list <boost-build_at_[hidden]>
>Cc: Daniel James <dnljms_at_[hidden]>
>Subject: Re: [Boost-build] MSVC toolset versions on VS2017
>
>On 20 November 2017 at 02:54, Tom Kent via Boost-build <boost-build_at_[hidden]> wrote:>
>>
>> The interesting part about version numbers is three-quarters of the 
>> way down the post, under the "MSVC toolset version number increases to 14.12".
>>
>> The table that they have there is also illuminating:
>>
>> Visual Studio Version   |   MSVC Toolset Version  |  _MSC_VER
>> ---------------------------------------------------------------
>> VS2015 and updates 1, 2, & 3 | v140 in VS; version 14.00 | 1900 
>> VS2017, Version 15.1 & 15.2  | v141 in VS; version 14.10 | 1910 
>> VS2017, Version 15.3 & 15.4  | v141 in VS; version 14.11 | 1911
>> VS2017, Version 15.5         | v141 in VS; version 14.12 | 1912
>> ---------------------------------------------------------------
>
>IIUC as 14.12 is still v141, which we call 14.1 in build, boost build will treat 14.10-14.12 as the same version. I think that's what most people would expect, but it's apparently going to be possible to install minor versions side-by-side now, is that something we should support? It's not supposed to be something that most people use, but testers might want to. There's a 'vcvars_ver' parameter to vcvarsall.bat to specify the version. Details are in this blog post:

[AP] MSVC is learning to deal with its fear of version numbers (Hauptversionsnummernerhöhungsangst, for those of you who pay attention to the internets.) Major version numbers (e.g., 14) and minor versions numbers (e.g., .12) now make sense. When we have a major, binary breaking revision to the compiler we rev the major version number. When we have a significant, but non-binary breaking change, we rev the minor version number. When we just ship bug fixes (15.1, 15.2, 15.4) we don't touch the version number. The third part of the version number--the build date--is always reved. The fourth part of the version number--the build number--is just .00 unless there was a build break requiring rebuild.  

There are two old errors that will be corrected with the next major version, v20.00:

1. The entire toolset will be 20.00. No longer will the linker and VS be 5 versions lower than the compiler. We're all going to jump to 20. (For the compiler, it's a jump of one.)
2. I intend to have VS display the entire major/minor toolset version. Developers will select 20.00 or 20.01 or 20.10 instead of "v200" in VS. If I fail partially, developers will select "20.0x". If I fail completely, then you have the same madness to deal with that we have today : ) 

We really, really don't want people using the minor versions. It is meant as an escape hatch only for largely impactful, unanticipated bugs. We won't be able to service or support these minor versions in any way and they should be considered insecure the minute we make a security fix to a current version. That said, the cat is out of the box so we know it's alive and we're gonna have to feed it. 

>https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/