On 10/4/15 1:10 AM, Gennadiy Rozental wrote:
Tom Kent
writes: Unfortunately I know lots of places that are still using msvc-8.0, so I don't see that full move happening any time soon
Why would we want to wait for some places using 12 year old compiler? More importantly who is going to maintain the code for it? If they want to stick with older compiler, they can stick with older boost release.
I think this betrays a difference in what Boost or what Boost should be. To some, it seems that "The Boost Libraries" is sort of like a product like windows, or Clang or whatever - a large piece of code with lots of facets which is accepted/rejected as a whole. This is what most of us deal with in our day jobs so it seems natural to look at Boost this way. This view leads to coupling among libraries, requirements for coordination on testing policies, and things like that. I don't think this is a good think I think a better way to look at Boost is a collection of more loosely coupled software components. The only coupling is to a minimal set of of practices and requirements: Compatiblity with C++, Formal Review, directory structure, and documentation requirements. In this view, there is no place for requiring a specific library for testing, requiring that some particular version of C++ not be supported. I have no problems with the current setup as regards the serialization library - a library which has more stringent requirements than most in the support of older code, platforms and data sets. I use a) Xcode/CLang with C++11 enabled for development as it's very convenient for this. b) I use my own version lightweight test as it's enough for my needs and I've found it simpler and more stable than other systems. I haven't changed any code in it for ten years!. A big problem in using boost test on the test matrix is that one is testing my development code with boost test development code so when the later has some issue, it spills over into my domain - and I already have my hands full. c) I have my whole boost development tree to set to master branch so I'm testing against the next release. Only the serialization submodule is set to develop (or a feature branch). d) Almost most all code is C++11/C++03 agnostic. e) Some code is C++11+ specific. This is conditioned with BOOST_NO... macros. Some tests are conditioned on these macros as well. f) After I get clean results with Xcode/CLang C++11 I test with GCC with C++03 selected. Tweak the library to address any test failures then upload to development branch of the repository. This is a simple effective system which has worked well for me and I believe for the wide variety of users of the serialization libraries. It is not particularly difficult or time consuming to maintain - given the size and complexity of the library itself. Notice that it does NOT result in maintaining two versions of the library. A very small portion of the code is conditional. I don't think can or should try to impose requirements/prohibitions on supporting old libraries from the top down. It isn't a requirement, but it it can't be prohibited either. If the author of Boost.Test feels he can't support older compilers, that's his decision of course. But he should be aware it's going to cut his "market share" and encourage the usage of alternatives. Robert Ramey