[release] 1.64.0 Delayed because of Microsoft (version numbers)

Rene Rivera

17 Mar 2017 17 Mar '17

3:12 p.m.

Sorry to say the beta release of 1.64.0 is hereby going to be delayed for at least another week. The confusion of VS2017 version numbers and the communities inability to address this issue after the beta is to blame. To address the situation the beta release will be published when one of the two tasks below are completed: (A) Boost Config changes to use 1410 as the autolink version to match what the currently working generated libs are taggeg with. Or: (B) The community decides what version number we should be using and the appropriate PRs are filed and applied and tested for all the repos involved. Which means: 1. The community has until 12:00 CDT US March 18 to decide on what the vc version number and tag should be. 2. The community must post PRs for the places where we reference VS2017 version numbers to the new number. Those are at least: https://github.com/boostorg/config https://github.com/boostorg/build https://github.com/boostorg/boost https://github.com/boostorg/website People have until 17:00 CDT Monday March 20 to submit those PRs. 3. The community can test the resulting master snapshot when available at the latest 24:00 Monday March 20. 4. If all goes well we can have a beta release on Wednesday March 22 (ie one week late). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Show replies by date

John Maddock

17 Mar 17 Mar

6:08 p.m.

On 17/03/2017 15:12, Rene Rivera via Boost wrote:

...

Sorry to say the beta release of 1.64.0 is hereby going to be delayed for at least another week. The confusion of VS2017 version numbers and the communities inability to address this issue after the beta is to blame.

To address the situation the beta release will be published when one of the two tasks below are completed:

(A) Boost Config changes to use 1410 as the autolink version to match what the currently working generated libs are taggeg with.

I've cherry picked the relevant commits to master and pushed those - so Config and Build are consistent now. However, IMO the name used is just plain wrong - note that both Peter Dimov and myself have both typed in the "wrong" name by mistake *even when we know what the "right" name is*. Worse, if you do type in toolset=msvc-14.1 by mistake, something (not sure what) still happens and libraries with a "141" suffix are generated, IMO we need to fix that before release, though not necessarily before beta. John.

...

Or:

(B) The community decides what version number we should be using and the appropriate PRs are filed and applied and tested for all the repos involved. Which means:

1. The community has until 12:00 CDT US March 18 to decide on what the vc version number and tag should be.

2. The community must post PRs for the places where we reference VS2017 version numbers to the new number. Those are at least:

https://github.com/boostorg/config https://github.com/boostorg/build https://github.com/boostorg/boost https://github.com/boostorg/website

People have until 17:00 CDT Monday March 20 to submit those PRs.

3. The community can test the resulting master snapshot when available at the latest 24:00 Monday March 20.

4. If all goes well we can have a beta release on Wednesday March 22 (ie one week late).

--- This email has been checked for viruses by AVG. http://www.avg.com

Tom Kent

19 Mar 19 Mar

12:55 p.m.

On Fri, Mar 17, 2017 at 1:08 PM, John Maddock via Boost < boost@lists.boost.org> wrote:

...

On 17/03/2017 15:12, Rene Rivera via Boost wrote:

...
Sorry to say the beta release of 1.64.0 is hereby going to be delayed for at least another week. The confusion of VS2017 version numbers and the communities inability to address this issue after the beta is to blame.

To address the situation the beta release will be published when one of the two tasks below are completed:

(A) Boost Config changes to use 1410 as the autolink version to match what the currently working generated libs are taggeg with.

I've cherry picked the relevant commits to master and pushed those - so Config and Build are consistent now.

I don't think this happened...it looks like master auto_link.hpp is using vc141 not vc1410. Develop looks like it matches what build is doing. https://github.com/boostorg/config/blob/master/include/boost/config/auto_lin... IMO this is still blocking beta.

...

However, IMO the name used is just plain wrong - note that both Peter Dimov and myself have both typed in the "wrong" name by mistake *even when we know what the "right" name is*. Worse, if you do type in toolset=msvc-14.1 by mistake, something (not sure what) still happens and libraries with a "141" suffix are generated, IMO we need to fix that before release, though not necessarily before beta.

I agree. Most users won't even know to try 14.?? to use VS 2017, because MS clearly labels it everwhere as "15", but it is definitely more correct for us to match MS's c++ tools than the visual studio version. Anyway, once users figure that out, they'll be much more likely to use 14.1 vs. 14.10...there was no 14.2, 14.3, 14.9 etc!

Edward Diener

17 Mar 17 Mar

8:22 p.m.

On 3/17/2017 11:12 AM, Rene Rivera via Boost wrote:

...

Sorry to say the beta release of 1.64.0 is hereby going to be delayed for at least another week. The confusion of VS2017 version numbers and the communities inability to address this issue after the beta is to blame.

To address the situation the beta release will be published when one of the two tasks below are completed:

(A) Boost Config changes to use 1410 as the autolink version to match what the currently working generated libs are taggeg with.

Or:

(B) The community decides what version number we should be using and the appropriate PRs are filed and applied and tested for all the repos involved. Which means:

1. The community has until 12:00 CDT US March 18 to decide on what the vc version number and tag should be.

2. The community must post PRs for the places where we reference VS2017 version numbers to the new number. Those are at least:

https://github.com/boostorg/config https://github.com/boostorg/build https://github.com/boostorg/boost https://github.com/boostorg/website

People have until 17:00 CDT Monday March 20 to submit those PRs.

3. The community can test the resulting master snapshot when available at the latest 24:00 Monday March 20.

4. If all goes well we can have a beta release on Wednesday March 22 (ie one week late).

I have discovered that Visual Studio 2017 itself actually has no current documentation available, so even Microsoft has released its own product before it should even have been released. Therefore I think you are doing the absolutely correct thing and there is no point in trying to rush Boost 1.64 until the issue with VS2017 version numbers are tested and resolved. Thanks for all the work that you and others have done and are doing to resolve this issue.

Glen Fernandes

18 Mar 18 Mar

12:57 a.m.

On Fri, Mar 17, 2017 at 4:22 PM, Edward Diener via Boost wrote:

...

I have discovered that Visual Studio 2017 itself actually has no current documentation available, so even Microsoft has released its own product before it should even have been released. Therefore I think you are doing the absolutely correct thing and there is no point in trying to rush Boost 1.64 until the issue with VS2017 version numbers are tested and resolved. Thanks for all the work that you and others have done and are doing to resolve this issue.

+1, my gratitude/appreciation also to Rene and everyone involved in this release. Does master open up for changes after the beta release on Wednesday, or earlier/now, due to the delay? (I almost expected we would release and wait for 1.65 to support VS2017 fully). Glen

Rene Rivera

1:41 a.m.

On Fri, Mar 17, 2017 at 7:57 PM, Glen Fernandes via Boost < boost@lists.boost.org> wrote:

...

Does master open up for changes after the beta release on Wednesday, or earlier/now, due to the delay?

We are more likely to say yes to master merge requests with the delay. But you still need permission. After the beta it will be entirely open, as usual. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Tom Kent

19 Mar 19 Mar

1:10 p.m.

On Fri, Mar 17, 2017 at 10:12 AM, Rene Rivera via Boost < boost@lists.boost.org> wrote:

...

(B) The community decides what version number we should be using and the appropriate PRs are filed and applied and tested for all the repos involved. Which means:

1. The community has until 12:00 CDT US March 18 to decide on what the vc version number and tag should be.

2. The community must post PRs for the places where we reference VS2017 version numbers to the new number. Those are at least:

https://github.com/boostorg/config https://github.com/boostorg/build https://github.com/boostorg/boost https://github.com/boostorg/website

People have until 17:00 CDT Monday March 20 to submit those PRs.

3. The community can test the resulting master snapshot when available at the latest 24:00 Monday March 20.

4. If all goes well we can have a beta release on Wednesday March 22 (ie one week late).

I'm not sure how we'll coalesce around a consensus, but I figure we should lay out the options in one place. Even if this doesn't make it into the beta, we should be clear on this going forward. Option 1 - 14.10 Use microsoft toolset version based on cl.exe version -5. This is the official version of the c++ toolset that microsoft has been pushing (somewhere). The new $(VCToolsVersion) macro is "14.10.25017", this macro is not available in previous versions of visual studio. build bootstrap would use bootstrap.bat vc1410 build of source would use b2 toolset=msvc-14.10 build would generat libraries of the format libboost_NAME_vc1410-OPTIONS-1_64.lib config would auto-link libraries of the same format Option 2 - 14.1 Use the abbreviated toolset version that microsoft uses for their toolset version. The $(PlatformToolsetVersion) macro is "141". In VS2015 this was "140". build bootstrap would use bootstrap.bat vc141 build of source would use b2 toolset=msvc-14.1 build would generat libraries of the format libboost_NAME_vc141-OPTIONS-1_64.lib config would auto-link libraries of the same format Option 3 - 15.0 Use the visual studio version. The $(VisualStudioVersion) macro is "15.0". In VS2015 this was "14.0". build bootstrap would use bootstrap.bat vc15 build of source would use b2 toolset=msvc-15.0 build would generat libraries of the format libboost_NAME_vc150-OPTIONS-1_64.lib config would auto-link libraries of the same format A alternative that could be made to any of the options 1-3 option would be to bring the b2 toolset in line with whatever we chose for the name, replacing the "msvc-" with "vc". For example option 1-a would be: build bootstrap would use bootstrap.bat vc1410 build of source would use b2 toolset=vc1410 build would generat libraries of the format libboost_NAME_vc1410-OPTIONS-1_64.lib config would auto-link libraries of the same format I *think* that is all the reasonable options. Let the consensus form! Tom

Tom Kent

1:15 p.m.

On Sun, Mar 19, 2017 at 8:10 AM, Tom Kent wrote:

...

On Fri, Mar 17, 2017 at 10:12 AM, Rene Rivera via Boost < boost@lists.boost.org> wrote:

...
(B) The community decides what version number we should be using and the appropriate PRs are filed and applied and tested for all the repos involved. Which means:

1. The community has until 12:00 CDT US March 18 to decide on what the vc version number and tag should be.

2. The community must post PRs for the places where we reference VS2017 version numbers to the new number. Those are at least:

https://github.com/boostorg/config https://github.com/boostorg/build https://github.com/boostorg/boost https://github.com/boostorg/website

People have until 17:00 CDT Monday March 20 to submit those PRs.

3. The community can test the resulting master snapshot when available at the latest 24:00 Monday March 20.

4. If all goes well we can have a beta release on Wednesday March 22 (ie one week late).

I'm not sure how we'll coalesce around a consensus, but I figure we should lay out the options in one place. Even if this doesn't make it into the beta, we should be clear on this going forward.

Option 1 - 14.10 Use microsoft toolset version based on cl.exe version -5. This is the official version of the c++ toolset that microsoft has been pushing (somewhere). The new $(VCToolsVersion) macro is "14.10.25017", this macro is not available in previous versions of visual studio.

build bootstrap would use bootstrap.bat vc1410 build of source would use b2 toolset=msvc-14.10 build would generat libraries of the format libboost_NAME_vc1410-OPTIONS- 1_64.lib config would auto-link libraries of the same format

Option 2 - 14.1 Use the abbreviated toolset version that microsoft uses for their toolset version. The $(PlatformToolsetVersion) macro is "141". In VS2015 this was "140".

build bootstrap would use bootstrap.bat vc141 build of source would use b2 toolset=msvc-14.1 build would generat libraries of the format libboost_NAME_vc141-OPTIONS-1_ 64.lib config would auto-link libraries of the same format

Option 3 - 15.0 Use the visual studio version. The $(VisualStudioVersion) macro is "15.0". In VS2015 this was "14.0".

build bootstrap would use bootstrap.bat vc15 build of source would use b2 toolset=msvc-15.0 build would generat libraries of the format libboost_NAME_vc150-OPTIONS-1_ 64.lib config would auto-link libraries of the same format

A alternative that could be made to any of the options 1-3 option would be to bring the b2 toolset in line with whatever we chose for the name, replacing the "msvc-" with "vc". For example option 1-a would be:

build bootstrap would use bootstrap.bat vc1410 build of source would use b2 toolset=vc1410 build would generat libraries of the format libboost_NAME_vc1410-OPTIONS- 1_64.lib config would auto-link libraries of the same format

I *think* that is all the reasonable options. Let the consensus form!

Tom

I am in favor of option 2. Option 1 while most "correct" is waaaaay too far in the weeds for users. It doesn't play well with any built in "macros". It kills me that Option 3 isn't worthy, but this is completely microsoft's fault. Splitting the C++ toolset from the visual studio version was a terrible decision. There were better ways to indicate backwards compatibility with 14.0. The alternative for b2 toolset naming would be more consistent, but would just cause too many problems. We probably should have made this match back on VS.NET, but at that point we didn't know where microsoft was going with these versions. I'd say we're stuck with what we have. Tom

Paul A. Bristow

2:52 p.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Tom Kent via Boost Sent: 19 March 2017 13:15 To: Boost Developers List; Boost.Build developer's and user's list Cc: Tom Kent Subject: Re: [boost] [release] 1.64.0 Delayed because of Microsoft (version numbers)

On Sun, Mar 19, 2017 at 8:10 AM, Tom Kent wrote:

...
On Fri, Mar 17, 2017 at 10:12 AM, Rene Rivera via Boost < boost@lists.boost.org> wrote:

...
(B) The community decides what version number we should be using and the appropriate PRs are filed and applied and tested for all the repos involved. Which means:

1. The community has until 12:00 CDT US March 18 to decide on what the vc version number and tag should be.

2. The community must post PRs for the places where we reference VS2017 version numbers to the new number. Those are at least:

https://github.com/boostorg/config https://github.com/boostorg/build https://github.com/boostorg/boost https://github.com/boostorg/website

People have until 17:00 CDT Monday March 20 to submit those PRs.

3. The community can test the resulting master snapshot when available at the latest 24:00 Monday March 20.

4. If all goes well we can have a beta release on Wednesday March 22 (ie one week late).

I'm not sure how we'll coalesce around a consensus, but I figure we should lay out the options in one place. Even if this doesn't make it into the beta, we should be clear on this going forward.

Option 1 - 14.10 Use microsoft toolset version based on cl.exe version -5. This is the official version of the c++ toolset that microsoft has been pushing (somewhere). The new $(VCToolsVersion) macro is "14.10.25017", this macro is not available in previous versions of visual studio.

build bootstrap would use bootstrap.bat vc1410 build of source would use b2 toolset=msvc-14.10 build would generat libraries of the format libboost_NAME_vc1410-OPTIONS- 1_64.lib config would auto-link libraries of the same format

Option 2 - 14.1 Use the abbreviated toolset version that microsoft uses for their toolset version. The $(PlatformToolsetVersion) macro is "141". In VS2015 this was "140".

build bootstrap would use bootstrap.bat vc141 build of source would use b2 toolset=msvc-14.1 build would generat libraries of the format libboost_NAME_vc141-OPTIONS-1_ 64.lib config would auto-link libraries of the same format

Option 3 - 15.0 Use the visual studio version. The $(VisualStudioVersion) macro is "15.0". In VS2015 this was "14.0".

build bootstrap would use bootstrap.bat vc15 build of source would use b2 toolset=msvc-15.0 build would generat libraries of the format libboost_NAME_vc150-OPTIONS-1_ 64.lib config would auto-link libraries of the same format

A alternative that could be made to any of the options 1-3 option would be to bring the b2 toolset in line with whatever we chose for the name, replacing the "msvc-" with "vc". For example option 1-a would be:

build bootstrap would use bootstrap.bat vc1410 build of source would use b2 toolset=vc1410 build would generat libraries of the format libboost_NAME_vc1410-OPTIONS- 1_64.lib config would auto-link libraries of the same format

I *think* that is all the reasonable options. Let the consensus form!

What a shambles :-(

...

I am in favor of option 2. - as the least worst.

+1 NAME == $(PlatformToolsetVersion) Paul PS What happened to plans to change the name to include the address-model? (So that all the library files can be dumped into one folder). Although I am now quite happy using two folders that I have called /win32 and /x64 (both fairly daft names but with at least a tiny amount of logic), it requires a cunning boost.props file to make it work invisibly, and a more complex build .bat to push the two variants into the right folder. Isn't the whole (excellent) idea of auto-linking to make it simple? --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Gavin Lambert

20 Mar 20 Mar

10:45 p.m.

On 20/03/2017 03:52, Paul A. Bristow wrote:

...

...
I am in favor of option 2. - as the least worst.

+1

NAME == $(PlatformToolsetVersion)

+1 from me too.

...

Option 4 (141 and 14.10) - build bootstrap would use bootstrap.bat vc141 build of source would use b2 toolset=msvc-14.10 build would generat libraries of the format libboost_NAME_vc141-OPTIONS-1_ 64.lib config would auto-link libraries of the same format (4-a is the same as 2-a)

This also makes a certain amount of sense but I worry that 14.10 is potentially more confusing as it seems inconsistent with the other values, despite being technically more "correct". As John Maddock noted it's easy to get wrong at present even when you know what's correct.

...

PS What happened to plans to change the name to include the address-model? (So that all the library files can be dumped into one folder).

Although I am now quite happy using two folders that I have called /win32 and /x64 (both fairly daft names but with at least a tiny amount of logic), it requires a cunning boost.props file to make it work invisibly, and a more complex build .bat to push the two variants into the right folder.

Isn't the whole (excellent) idea of auto-linking to make it simple?

There is a way to do that currently using the build id: http://stackoverflow.com/a/42408982/43534 I agree that it would be nice if it happened automatically, though.

Peter Dimov

19 Mar 19 Mar

3:15 p.m.

Tom Kent wrote:

...

Option 2 - 14.1 Use the abbreviated toolset version that microsoft uses for their toolset version. The $(PlatformToolsetVersion) macro is "141". In VS2015 this was "140".

build bootstrap would use bootstrap.bat vc141 build of source would use b2 toolset=msvc-14.1 build would generat libraries of the format libboost_NAME_vc141-OPTIONS-1_64.lib config would auto-link libraries of the same format

+1.

Daniel James

3:17 p.m.

On 19 March 2017 at 13:10, Tom Kent via Boost wrote:

...

Option 1 - 14.10 Use microsoft toolset version based on cl.exe version -5. This is the official version of the c++ toolset that microsoft has been pushing (somewhere). The new $(VCToolsVersion) macro is "14.10.25017", this macro is not available in previous versions of visual studio.

build bootstrap would use bootstrap.bat vc1410

[snip]

...

Option 2 - 14.1 Use the abbreviated toolset version that microsoft uses for their toolset version. The $(PlatformToolsetVersion) macro is "141". In VS2015 this was "140".

[snip]

...

I *think* that is all the reasonable options. Let the consensus form!

I disagree, I think we should limit ourselves to values that Microsoft actually uses. As far as I'm aware, they don't use 1410, and they don't use 14.1. There are already too many ways of writing the version number, adding more will just add to the confusion. We should also make as few assumptions about the correspondence between different version numbers as possible. We shouldn't assume that the toolset version is the compiler minus 5. Similarly the idea that there's a fixed correspondence between whatever 141 and 14.10 represents, we should try to deal with the possibility 142 - 14.10, 141 - 14.11, 142 - 14.11 and 237 - 18.65, or whatever Microsoft does 10 years down the line.

Beman Dawes

20 Mar 20 Mar

1:05 p.m.

On Sun, Mar 19, 2017 at 11:17 AM, Daniel James via Boost < boost@lists.boost.org> wrote:

...

On 19 March 2017 at 13:10, Tom Kent via Boost wrote:

...
Option 1 - 14.10 Use microsoft toolset version based on cl.exe version

...
This is the official version of the c++ toolset that microsoft has been pushing (somewhere). The new $(VCToolsVersion) macro is "14.10.25017",

-5. this

...
macro is not available in previous versions of visual studio.

build bootstrap would use bootstrap.bat vc1410

[snip]

...
Option 2 - 14.1 Use the abbreviated toolset version that microsoft uses for their toolset version. The $(PlatformToolsetVersion) macro is "141". In VS2015 this was "140".

[snip]

...
I *think* that is all the reasonable options. Let the consensus form!

I disagree, I think we should limit ourselves to values that Microsoft actually uses. As far as I'm aware, they don't use 1410, and they don't use 14.1. There are already too many ways of writing the version number, adding more will just add to the confusion.

...

We should also make as few assumptions about the correspondence between different version numbers as possible. We shouldn't assume that the toolset version is the compiler minus 5. Similarly the idea that there's a fixed correspondence between whatever 141 and 14.10 represents, we should try to deal with the possibility 142 - 14.10, 141 - 14.11, 142 - 14.11 and 237 - 18.65, or whatever Microsoft does 10 years down the line.

+1 --Beman

Refael Ackermann

12:43 p.m.

On Sun, 19 Mar 2017 08:10:37 -0500 Tom Kent via Boost wrote:

...

On Fri, Mar 17, 2017 at 10:12 AM, Rene Rivera via Boost < boost@lists.boost.org> wrote:

...
(B) The community decides what version number we should be using and the appropriate PRs are filed and applied and tested for all the repos involved. Which means:

1. The community has until 12:00 CDT US March 18 to decide on what the vc version number and tag should be.

2. The community must post PRs for the places where we reference VS2017 version numbers to the new number. Those are at least:

https://github.com/boostorg/config https://github.com/boostorg/build https://github.com/boostorg/boost https://github.com/boostorg/website

People have until 17:00 CDT Monday March 20 to submit those PRs.

3. The community can test the resulting master snapshot when available at the latest 24:00 Monday March 20.

4. If all goes well we can have a beta release on Wednesday March 22 (ie one week late).

I'm not sure how we'll coalesce around a consensus, but I figure we should lay out the options in one place. Even if this doesn't make it into the beta, we should be clear on this going forward.

Option 1 - 14.10 Use microsoft toolset version based on cl.exe version -5. This is the official version of the c++ toolset that microsoft has been pushing (somewhere). The new $(VCToolsVersion) macro is "14.10.25017", this macro is not available in previous versions of visual studio.

build bootstrap would use bootstrap.bat vc1410 build of source would use b2 toolset=msvc-14.10 build would generat libraries of the format libboost_NAME_vc1410-OPTIONS-1_64.lib config would auto-link libraries of the same format

Option 2 - 14.1 Use the abbreviated toolset version that microsoft uses for their toolset version. The $(PlatformToolsetVersion) macro is "141". In VS2015 this was "140".

build bootstrap would use bootstrap.bat vc141 build of source would use b2 toolset=msvc-14.1 build would generat libraries of the format libboost_NAME_vc141-OPTIONS-1_64.lib config would auto-link libraries of the same format

Option 3 - 15.0 Use the visual studio version. The $(VisualStudioVersion) macro is "15.0". In VS2015 this was "14.0".

build bootstrap would use bootstrap.bat vc15 build of source would use b2 toolset=msvc-15.0 build would generat libraries of the format libboost_NAME_vc150-OPTIONS-1_64.lib config would auto-link libraries of the same format

A alternative that could be made to any of the options 1-3 option would be to bring the b2 toolset in line with whatever we chose for the name, replacing the "msvc-" with "vc". For example option 1-a would be:

build bootstrap would use bootstrap.bat vc1410 build of source would use b2 toolset=vc1410 build would generat libraries of the format libboost_NAME_vc1410-OPTIONS-1_64.lib config would auto-link libraries of the same format

I *think* that is all the reasonable options. Let the consensus form!

Tom

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

I'm for Option 1. Might be more "breaking" but I think it'll be more future proof (i.e. vc1412 > vc1410 && 14.20 > 14.12 14.10). Also People will need to familiarise themselfs with $(VCToolsVersion) == "14.10.25017", as it's now part of cl.exe's path (e.g. "D:\bin\dev\VS\2017\BuildTools\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\cl.exe") What a clusterf**k... MS, SHM... -- Refael Ackermann

Mateusz Loskot

1:38 p.m.

On 20 March 2017 at 13:43, Refael Ackermann via Boost wrote:

...

On Sun, 19 Mar 2017 08:10:37 -0500 Tom Kent via Boost wrote:

...
On Fri, Mar 17, 2017 at 10:12 AM, Rene Rivera via Boost < boost@lists.boost.org> wrote:

...
(B) The community decides what version number we should be using and the appropriate PRs are filed and applied and tested for all the repos involved. Which means:

1. The community has until 12:00 CDT US March 18 to decide on what the vc version number and tag should be.

2. The community must post PRs for the places where we reference VS2017 version numbers to the new number. Those are at least:

https://github.com/boostorg/config https://github.com/boostorg/build https://github.com/boostorg/boost https://github.com/boostorg/website

People have until 17:00 CDT Monday March 20 to submit those PRs.

3. The community can test the resulting master snapshot when available at the latest 24:00 Monday March 20.

4. If all goes well we can have a beta release on Wednesday March 22 (ie one week late).

I'm not sure how we'll coalesce around a consensus, but I figure we should lay out the options in one place. Even if this doesn't make it into the beta, we should be clear on this going forward.

Option 1 - 14.10 Use microsoft toolset version based on cl.exe version -5. This is the official version of the c++ toolset that microsoft has been pushing (somewhere). The new $(VCToolsVersion) macro is "14.10.25017", this macro is not available in previous versions of visual studio.

build bootstrap would use bootstrap.bat vc1410 build of source would use b2 toolset=msvc-14.10 build would generat libraries of the format libboost_NAME_vc1410-OPTIONS-1_64.lib config would auto-link libraries of the same format

Option 2 - 14.1 Use the abbreviated toolset version that microsoft uses for their toolset version. The $(PlatformToolsetVersion) macro is "141". In VS2015 this was "140".

build bootstrap would use bootstrap.bat vc141 build of source would use b2 toolset=msvc-14.1 build would generat libraries of the format libboost_NAME_vc141-OPTIONS-1_64.lib config would auto-link libraries of the same format

Option 3 - 15.0 Use the visual studio version. The $(VisualStudioVersion) macro is "15.0". In VS2015 this was "14.0".

build bootstrap would use bootstrap.bat vc15 build of source would use b2 toolset=msvc-15.0 build would generat libraries of the format libboost_NAME_vc150-OPTIONS-1_64.lib config would auto-link libraries of the same format

A alternative that could be made to any of the options 1-3 option would be to bring the b2 toolset in line with whatever we chose for the name, replacing the "msvc-" with "vc". For example option 1-a would be:

build bootstrap would use bootstrap.bat vc1410 build of source would use b2 toolset=vc1410 build would generat libraries of the format libboost_NAME_vc1410-OPTIONS-1_64.lib config would auto-link libraries of the same format

I *think* that is all the reasonable options. Let the consensus form!

I'm for Option 1. Might be more "breaking" but I think it'll be more future proof (i.e. vc1412 > vc1410 && 14.20 > 14.12 14.10).

I don't think this is argument holds strong in practice. AFAIK, PlatformToolseVersion and its derivatives used in Boost are never compared as range, like _MSC_VER often is, but as exact values. Boost tests for: v140 v141 and, if at any time Microsoft replaces it with, STL (tm): meow let it be so. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Andrew Pardoe

5:19 p.m.

Folks, I'm just now looking at this thread. Rafael kindly pinged me on GitHub--I don't normally pay attention to the Boost list.

Stephan T. Lavavej

9:17 p.m.

[Mateusz Loskot]

...

I don't think this is argument holds strong in practice. AFAIK, PlatformToolseVersion and its derivatives used in Boost are never compared as range, like _MSC_VER often is, but as exact values. Boost tests for: v140 v141 and, if at any time Microsoft replaces it with, STL (tm): meow let it be so.

FYI, we're planning to release a toolset that will be binary-incompatible with v140 and v141 at some point in the future (the libraries, and probably the compiler too, will be bin-incompatible, to allow us to make significant improvements to data structure layout and so forth that we're otherwise unable to make). We haven't decided on that toolset's versioning at this point. (I expect/hope that it will be very distinctive and not easily confused with the current versions; Visual C++ vMeow does have a nice ring to it...) STL

Mateusz Loskot

9:39 p.m.

On 20 March 2017 at 22:17, Stephan T. Lavavej wrote:

...

[Mateusz Loskot]

...
I don't think this is argument holds strong in practice. AFAIK, PlatformToolseVersion and its derivatives used in Boost are never compared as range, like _MSC_VER often is, but as exact values. Boost tests for: v140 v141 and, if at any time Microsoft replaces it with, STL (tm): meow let it be so.

FYI, we're planning to release a toolset that will be binary-incompatible with v140 and v141 at some point in the future (the libraries, and probably the compiler too, will be bin-incompatible, to allow us to make significant improvements to data structure layout and so forth that we're otherwise unable to make).

Thanks Stephan, I always appreciate all the updates and clarifications you give.

...

We haven't decided on that toolset's versioning at this point. (I expect/hope that it will be very distinctive and not easily confused with the current versions; Visual C++ vMeow does have a nice ring to it...)

+1 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

degski

21 Mar 21 Mar

2:17 p.m.

On 20 March 2017 at 15:39, Mateusz Loskot via Boost wrote:

...

Thanks Stephan, I always appreciate all the updates and clarifications you give.

It seems though that, the "updates and clarifications" are a bit short on facts. Of course Microsoft is going to issue an binary incompatible tool-chain in the future, this is just stating the obvious. Some clear advice on how to tackle the current issue, or a decision on future versioning (which would probably make the solution to the current problem become obvious) would be more helpfull in my opinion. degski

Mateusz Loskot

2:34 p.m.

On 21 March 2017 at 15:17, degski via Boost wrote:

...

On 20 March 2017 at 15:39, Mateusz Loskot via Boost wrote:

...
Thanks Stephan, I always appreciate all the updates and clarifications you give.

[...] Some clear advice on how to tackle the current issue, or a decision on future versioning (which would probably make the solution to the current problem become obvious) would be more helpfull in my opinion.

No doubt, pity Microsoft has not stepped forward and lead the necessary updates in Boost. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Bo Persson

4:32 p.m.

On 2017-03-21 15:17, degski via Boost wrote:

...

On 20 March 2017 at 15:39, Mateusz Loskot via Boost wrote:

...
Thanks Stephan, I always appreciate all the updates and clarifications you give.

It seems though that, the "updates and clarifications" are a bit short on facts. Of course Microsoft is going to issue an binary incompatible tool-chain in the future, this is just stating the obvious.

I think the idea is that there will be additional toolchains released, perhaps quaterly, while the product is still called Visual Studio 2017. Some of these might be binary compatible, and some are very likely not. And STL would not be allowed to tell us when, even if he knew.

...

Some clear advice on how to tackle the current issue, or a decision on future versioning (which would probably make the solution to the current problem become obvious) would be more helpfull in my opinion.

At Microsoft this is a marketing decision, and not something you can ask the engineers to predict. They probably don't know much more than we do, until the big launch party. For example, who would have guessed that the Windows product numbers would be 7, 8, 8.1, and 10? With Visual Studio we seem to be at "8.1" now, so the marketing team can tell us "new and improved", but still just the same. Only better, but not different. That's what we get for having large corporations. Bo Persson

degski

5:54 p.m.

On 21 March 2017 at 10:32, Bo Persson via Boost wrote:

...

<snip>

I think you're wrong on most, if not all, points... degski

Bo Persson

6:25 p.m.

On 2017-03-21 18:54, degski via Boost wrote:

...

On 21 March 2017 at 10:32, Bo Persson via Boost wrote:

...
<snip>

I think you're wrong on most, if not all, points...

degski

Do you want to share some specific insights here, or just not want to believe this is so? Bo Persson

Olaf van der Spek

6:30 p.m.

On Tue, Mar 21, 2017 at 5:32 PM, Bo Persson via Boost wrote:

...

That's what we get for having large corporations.

What is the (real) problem though? Everything has been known for months. -- Olaf

Bo Persson

8:08 p.m.

On 2017-03-21 19:30, Olaf van der Spek via Boost wrote:

...

On Tue, Mar 21, 2017 at 5:32 PM, Bo Persson via Boost wrote:

...
That's what we get for having large corporations.

What is the (real) problem though? Everything has been known for months.

Some people didn't want to touch this because the software wasn't officially released. Now it is, and the problems remain. The same people seems like they don't want to believe this, but denial doesn't help. With a large corporation, like Microsoft, some problems are not engineering problems that we perhaps can understand. There will also be seemingly irrational things like showing a preview of a product called "15", then stamping the box with "2017", while the engineers versioned it v141. I haved worked for such organisations too. Shit happens! Bo Persson

Rene Rivera

2:57 a.m.

On Fri, Mar 17, 2017 at 10:12 AM, Rene Rivera wrote:

...

(B) The community decides what version number we should be using and the appropriate PRs are filed and applied and tested for all the repos involved. Which means:

1. The community has until 12:00 CDT US March 18 to decide on what the vc version number and tag should be.

OK.. Is there a consensus on this now? What is it? 2. The community must post PRs for the places where we reference VS2017

...

version numbers to the new number. Those are at least:

https://github.com/boostorg/config https://github.com/boostorg/build https://github.com/boostorg/boost https://github.com/boostorg/website

People have until 17:00 CDT Monday March 20 to submit those PRs.

I see PRs for the 14.1 & 141 changes thanks to Tom, and John. But no other PRs. Does that mean that's the default choice? I.e. Can someone summarize the state of the great version fiasco? :-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Olaf van der Spek

8:28 a.m.

On Tue, Mar 21, 2017 at 3:57 AM, Rene Rivera via Boost wrote:

...

OK.. Is there a consensus on this now? What is it?

141 and 14.1, as far as I can tell.

...

2. The community must post PRs for the places where we reference VS2017

...
version numbers to the new number. Those are at least:

https://github.com/boostorg/config https://github.com/boostorg/build https://github.com/boostorg/boost https://github.com/boostorg/website

People have until 17:00 CDT Monday March 20 to submit those PRs.

I see PRs for the 14.1 & 141 changes thanks to Tom, and John. But no other PRs. Does that mean that's the default choice? I.e. Can someone summarize the state of the great version fiasco? :-)

It's about to be fixed. ;) -- Olaf

2952

Age (days ago)

2956

Last active (days ago)

List overview

Download

26 comments

17 participants

participants (17)

Andrew Pardoe
Beman Dawes
Bo Persson
Daniel James
degski
Edward Diener
Gavin Lambert
Glen Fernandes
John Maddock
Mateusz Loskot
Olaf van der Spek
Paul A. Bristow
Peter Dimov
Refael Ackermann
Rene Rivera
Stephan T. Lavavej
Tom Kent