Re: [boost] Status of Visual Studio 2017 support

Subject: Re: [boost] Status of Visual Studio 2017 support
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-02-14 13:50:29

On 02/14/17 16:36, Olaf van der Spek via Boost wrote:
> On Tue, Feb 14, 2017 at 2:28 PM, Glen Fernandes via Boost
> <boost_at_[hidden]> wrote:
>>> Could anyone clarify any of these points:
>>> - Does Boost.Build in Boost 1.63.0 officially support VS2017?
>>> - Is there any schedule to fully support VS2017 in Boost 1.64.0?
>>> - Or, is that left at discretion of maintainers of individual libraries
>>> and VS2017 support might be reached gradually over several releases
>>> instead of in a single shot?
>>
>> Looking at the dates, that patch was in June 2016 when VS2017 was not
>> released yet, and Boost 1.63 was released in December 2016 when VS2017
>> had still not released yet. Seems normal that VS2017 isn't one of the
>> supported implementations yet.
>>
>> I imagine once VS2017/VC15/14.1 releases, the next Boost release after
>> that will aim to support it.
>>
>> By then we'll probably also have working testers at:
>> 1. http://www.boost.org/development/tests/master/developer/summary.html
>> 2. http://www.boost.org/development/tests/develop/developer/summary.html
>>
>> I see it happen organically (and generally quickly) once a new
>> implementation is officially released.
>
> RCs have been available for months and RTM/RTW will be March 7th.
>
> I don't get why the plan seems to be to wait for the final release.
> Doesn't it just delay the work that has to be done?
> Does it make the work significantly easier?

Yes, it does, because 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.

Personally, I think MSVC already consumes too much effort to support its 
new versions. For example, I don't see as much fuss about testing gcc or 
clang pre-releases - these get introduced silently to the test matrix, 
with apparently no required changes to Boost.Build or Boost.Config. 
(Well, the latter may need to be updated if a previously missing/broken 
feature is supported in the new compiler, but that is not a showstopper.)