On Sat, May 4, 2019 at 10:39 PM Robert Ramey via Boost
Perhaps this is a good opportunity to craft and test a procedure for a single library update.
Isn't this called "git pull" and build? If someone is going to take a patch of boost today, they can reasonably expect to have to build. What other little fixes are going to get slipped into 1.70.1? Surely there are other candidates too. I haven't seen a comprehensive plan put forth that would lead to modularization. Wouldn't that have to start with selection of a package manager capable of dealing with the versioning requirements and pre-built dependency acquisition? For example if I want to use boostorg/graph version 1.68.0, how do I tell something to download everything I need for that, repeatably, efficiently (see: don't re-download it if I have it and all the deps), for every build I do? How do I tell my build system where to find those things that were downloaded? Once that package manager is selected and each boost module declares the dependency and version requirements it has, and all boost modules moved into this system, then boost modules could update at will and there would be no more need for a monolithic release. Until then, we have 3 releases a year, which is really quite good for something this complex. - Jim