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

Subject: Re: [boost] Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*
From: M.A. van den Berg (thijs_at_[hidden])
Date: 2016-05-21 15:06:53

> On 21 May 2016, at 20:27, Robert Ramey <ramey_at_[hidden]> 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