Rene Rivera wrote:
By the way, do we really need to package a release on every commit to develop? :-)
Yes, it's needed. It's how I reduce the likelihood that merging to master will still work for the actual releases. We've had enough problems in the past with this last step not working that I'm ok with it running all the time.
Now that I took a second and third look, it occurs to me - and this may well be your plan - that the "ci_boost_status.py" part can actually parse the commit message ("Update foo, bar from develop") and then checkout foo, bar and their testing dependencies and run b2 libs/foo/test libs/bar/test toolset=... which would actually make it unnecessary for every library to add its own travis/appveyor integration. We'll just need to route the email notification to the proper person, or perhaps setup a dedicated mailing list for that, or do both. Actually... we could checkout the whole Boost, without dependency analysis, as a first step, and deal with dependencies later. The other VMs do that anyway. :-) This does not entirely replace per-library travis/appveyor integration because it will not test the library pull requests, but on the other hand, it requires zero effort on part of individual maintainers. And that is the outdated, Boost 1.x way, is it not? :-)