Re: [boost] Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*

On 21 May 2016, at 20:27, Robert Ramey wrote:

On 5/21/16 10:26 AM, Peter Dimov wrote:

...

Hartmut Kaiser wrote:

...

As said, I find the classification of a library as being 'C++14 only' to be completely useless.

Agreed - but maybe there is something interesting to consider.

Let's call it "Boost-Lite"

Boost-Lite would be subset of boost with minimal dependencies outside the standard library. So it would not include those parts of boost already incorporated inside the standard library: std::shared_ptr, etc. It would also not include boost component which which are superceeded by newer standard library features and components - no need for boost::type_of, etc.

If we want to break boost into smaller subsets then I would focus on modelling dependencies and versions and have an installer. This has been tried before -there are scripts that analyse boost inter-dependencies, there has been efforts to reduce these dependencies-. Dependencies could be made conditional (conditioned on assumed compiler capabilities), but I’ve never seen that (apt-get, npm, brew). It’ll probably easier to maintain various versions of libraries: one that requires C++14, another one that works with C++98 but with more boost dependencies that help fill the 98-14 gap. Personally I think allowing boost branded libraries (approved by boost, conforms to boost guidelines.. something like that) that are separately downloadable -just like any lib on Github really- can have many benefits: It allows for growth in the number of libraries, it decouples releases, abandoned libraries won’t hurt the quality of a release because there is no longer a monolithic releases. Boost is a band with a reputation, it imposes requirement on libraries that help build that reputation. A monolithic release is not an essential aspect for that. With a monolithic release we get an “all these libraries works together" quality guarantee. If we model versioned dependencies like all those other packet managers, then we still test if library X does indeed work correctly while having a dependency on library Y with version >=3.14