Boost logo

Boost :

Subject: Re: [boost] boost.test regression or behavior change (was Re: Boost.lockfree)
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-10-07 02:37:10


On 06-Oct-15 12:31 PM, M.A. van den Berg wrote:
>
> On 6 Oct 2015, at 11:17, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
>
>> On Tue, Oct 6, 2015 at 11:56 AM, M.A. van den Berg <thijs_at_[hidden]> wrote:
>>>
>>>>
>>>>> 3) Why make users change their code to use 'Test2' instead of 'Test',
>>>>> and then to 'Test3' in the future?
>>>>
>>>> That allows users to opt in to the changes.
>>>
>>> This is a clear example of the drawbacks of a monolithic boost distribution.
>>
>> What, exactly, and how it it related to monolithic structure? Opting
>> in for such breaking changes is the only sensible way, IMHO.
>>
>
> The way I see it, it that Test2, Test3 is poor-mans versioning effect by creating new libraries with version numbers added in the name, .. and then shipping all three of them in a boost release? This solution gives very limited version dependency capabilities.
>
> When boost moved to git there was an effort to reduce dependencies between libraries. One of wish -by some- was to have a future of boost where individual libraries and their version tagged dependencies would all be separate downloadable. This is not the current situation, of even a goal that’s on the agenda, but I wish it was. It would solve a lot of scalability issues IMO.

I think that's a little bit too abstract. If there are dozens of libraries that semantically depend on Boost.Test,
it does not matter in practice whether it's monolithic distribution or a fully modular one put together
on demand by supernatural powers - if end users actively use Boost libraries with C++03 and want to run tests, they need
Boost.Test.C++03. If there were 2 or 3 niche libraries with such dependency, the situation would be different,
but as it is now, this is painful breaking change regardless of distribution mechanics.

- Volodya


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk