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@lists.boost.org> 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