On Thu, May 14, 2015 at 11:10 AM, Niall Douglas
Boost 1.x is obsolete.
It is obsolete because enough of Boost 1.x is now in the STL that you no longer need to use Boost 1.x.
I don't think this is even close to accurate. It is true that a bunch of the C++11 stuff boost had first, and is now redundant...and even more of the C++11 stuff was built into boost. However, all that isn't more than about 15% of what boost does. Myself (as an end-user), I use python, test, interprocess, lexical_cast, date_time, filesystem, program_options, uuid and more...none of which are available in C++11, and most of those have no aspirations of being in any future standard.
It's also monolithic, and has a long list of structural problems. About half its libraries are undermaintained or not maintained. Many of the new authors wish their code as far away from it as possible because of the code smell. Quite frankly, as STL implementations get ever better, they are now better maintained and are of higher quality than Boost. In the end, STLs have a ton of full time engineers tending to them, Boost does not.
I agree that the monolithic nature is a big pain and the lack of maintenance is a bigger one, but I'm not sure that your solution is one that the majority of the current boost would ever make it into, if we even attempt to make a move like that. As and end user, I'd love to have a modular install, where just the libraries I need and their dependencies are installed. However, the more I think about it, it doesn't seem like that would be simple...the dependencies of the more useful libraries are (correctly) quite numerous. This makes sense, they are trying to do complicated things, so they take advantage of existing functionality to lower their own complexity....that is far better than trying to re-write existing stuff just to keep the dependency list down. I think we would be better served getting the more useful libraries outfitted with CI type testing (I really like the test matrix that is available on the AFIO page: https://github.com/BoostGSoC13/boost.afio) than trying to make a separate, modularized version of boost. However, if the group does decide to make a new version where the libraries are modularized, then I would like to suggest that we come up with a new name instead of Boost 2.0, still under the Boost organization umbrella. I think the changes suggested go far beyond a simple version revision. Tom