I am working on a C++ library for small microcontrollers (the thingies that typically have a few kilobytes of RAM). I might one day want to submit my work to boost. I'll respond from that perspective.
1. Boost isn't sexy any more. As one very highly respected world famous engineer put it - and I won't say who, and I apologise to him for stealing his words without attribution:
"Boost used to be about all the stuff you really wanted in the standard. Now Boost looks like all the stuff that wasn't good enough to get into the standard"
I think there is room for a collection of high-quality libraries that are too specialized or too experimental to be in the standard.
2. I personally want as far away from C++ 03 as soon as is possible.
Agreed. I write my code now, for the currently available compiler(s). For me that is the latest GCC, or maybe clang, or a vendor specific compiler (AFAIK VS isn't a cross-compiler for bare-metal targets, so it is not relevant, at least not for the target-dependent parts).
3. All the interesting new C++ 11 libraries you find around the internet have zero interest in trying to join Boost, with a very few honorable exceptions. That speaks volumes, to me at least.
I would be interesested, especially because of the review process.
1. Minimum required compiler feature set will be VS2014's. No use of Boost STL permitted where the C++ 11 STL provides a feature.
I totally agree
2. cmake instead of Boost.Build.
My libraries are headers-only, so I don't think this would matter much to me.
3. Eliminate peer review in favour of a suite of automated libclang based AST analysers. Instead of persuading people to review libraries, persuade them to review and improve the AST analysers.
Testing is of course fine, but it can not evaluate architecture or documentation.
4. Mandatory cross platform per-commit CI with unit testing exceeding 95% coverage. We don't care what unit test library is used so long as it can output results Jenkins can understand.
Agreed in general, but how would you realize that for code that is specific to a particular microcontroller?
5. Mandatory all green thread, memory, UB sanitisers and clean valgrind. All also tested per-commit.
"green thread"?? For the targets and applications I am interested in heap, exceptions, RTTI, and all other things that requires more than a few kB of code (that is nearly all standard libraries!) are out of the question.
6. Mandatory CI testing for exception safety. I am hoping a clang rewriter can basically patch all exception throws and have them randomly throw for testing.
7. Per-library source distributions
Yes!
10. BoostBook documentation using the Boost look and feel becomes mandatory. I've had enough with library authors thinking they can improve on BoostBook's output with things like using Comic Sans as the font or weird colour schemes throughout.
I have tried to make some sense of boostbook but I got nowhere. All documentation about it seems to assume I know how to do thins that I have never heard of. Note that I am mainly a Windows user. Wouter van Ooijen