Vladimir Prus-3 wrote
Turned out that github release system is fairly easy to use, so I should be able to push releases more often in future.
This is very interesting. The same comment could/should apply to all libraries. I think this is the direction we want to be moving to. But it raises a number of questions regarding: Deployment - full and partial what happens with the latest version of build (or any other library or tool depends upon something not release yet. How is this detected and controlled?). What happens when one want's to deeply a porting of boost via BCP or otherwise. Dependency management. We've discussed this before and I think this has been productive. But we still have some issues related to what dependencies we want to track. applications, tests, examples, library build etc. The there is the issue of "bridge libraries" which we're struggling with. Testing: Our testing infrastructure has served us very well. But I'm concerned that its coverage has begun to narrow to Clang, GCC and MSVC. I'm also concerned that it can't continue to scale. And finally we don't have a way to deal with partial deployments - which I believe we will eventually have to address. I have some ideas about some of these. I don't see a grand change. I think we've done very well in getting the "modular boost" working well. I'm hoping that we can leverage on that to evolve in a way which addresses the above concerns. Perhaps Vladimir's idea is a good place to start. We can do this and see how it works out. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Build-2014-10-tp4668736p4668746.htm... Sent from the Boost - Dev mailing list archive at Nabble.com.