Re: [boost] Status of Visual Studio 2017 support

Subject: Re: [boost] Status of Visual Studio 2017 support
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-02-14 21:58:14

On 2/14/2017 1:33 PM, Beman Dawes via Boost wrote:
> On Tue, Feb 14, 2017 at 1:07 PM, Stephan T. Lavavej via Boost <
> boost_at_[hidden]> wrote:
>
>> [Andrey Semashev]
>>> the final release may be significantly different from the pre-released
>> versions.
>>> It is not unheard of entire features being removed or modified in the
>> final release.
>>
>> Our process is that between Previews and RC, we enter "ask mode" (ask for
>> permission to make changes), and between RC and RTM we enter "escrow mode",
>> which is a very strict lockdown. The only bugs that are fixed in escrow
>> mode are of the form "it's melting users' hard drives and the metal fumes
>> are making people dizzy".
>>
>> VS 2017 is a little different than before (in that we've intentionally had
>> 4 release candidates so far, although not prominently branded as such), but
>> we're definitely locked down now. A useful heuristic is that when we've
>> publicly announced the release date for RTM, as we recently did (March 7),
>> the time for major changes is long past.
>>
>> The toolset (compiler/linker/libraries), which is what Boost is interested
>> in, also locks down before the rest of the product, because we're at a low
>> level in the stack. Throughout 10 years in Visual C++, I've taken several
>> fixes through ask mode, but never through escrow mode that I can recall.
>> We're focused on the next toolset update at the moment.
>>
>> For Boost, the policy I would recommend is: treat Previews as unsupported
>> (major feature changes in them), but attempt to support RC builds when they
>> appear. This will lead to better synchronization between Boost and VS
>> releases.
>>
>
> +1
>
> Times of changed; Microsoft and other compiler vendors used to be very
> close lipped about what would actually be in a release. Nowadays the C++
> community gets lots of notice and multiple release candidates well ahead of
> releases. There is much more openness, and lots of two-way conversations,
> both public and private. Times have changed.
>
> The Visual Studio 2017 release is big deal - it means all major compilers
> now support virtually all C++11 and C++14 features, and Boost library
> maintainers can drop support for non-C++11 compilers in good conscience.

I do no think it is that easy. There are probably still some end-users 
not compiling in C++11 mode on up, and dropping support for non-C++11 
compilers in the form of using C++11 on up features in code is going to 
leave those people behind. How about the more reasonable: if you are 
creating a new library use c++11 on up whereas if you are supporting an 
old library think about whether or not you want to lose end-users by 
using C++11 on up without checking Boost Config support for such features.

> The sooner Boost Build and other aspects of boost support msvc 2017, the
> better, IMO.

Should I dare ask whether msvc 2017 has fixed its non-standard 
proprocessor so that it follows the C++ standard ? I think not, as I 
don't want to be disappointed by the answer.

>
> --Beman