2013/1/1 Rob Stewart <robertstewart@comcast.net>
That leaves only four options for Boost:
1. Ignore C++11 compatibility. 2. Provide exactly C++11 API and behavior. 3. Provide 2 plus pure extensions. 4. Provide both 1 and 2 via two namespaces or classes.
If vincent wants some users opinion, I'm all for option 1 or 4. I know that option 4 is a maintenance nightmare, so sticking with option 1 is fine for me. I'm concerned about distribution maintenance. Boost.Thread is not a header library. so it is packaged once for all applications in a linux distribution (like debian). breaking compatibility on a header only library is not a problem, but for the other few dynamic libraries of boost, breaking compatibility is a big deal beacause you can't have control. One application might still use the old behaviour, as the other using the new one. this can't be solved using a macro definition. using a macro would be a distribution patching nightmare. more than the boost distribution cost of maintaining two distinct namespaces for old and new behaviour. For boost maintainers, i know that it's a really hard job to maintain a library. But when releasing a dynamic library for boost you should keep API and ABI backward compatibility if you announce that you support linux. I know a lot of the maintainers only care for windows or mac and have a point of view that the application developper is in charge of his software dependancy and build tool chain... but it's not true in linux domain. please keep it in mind.