Re: [boost] boost.test regression or behavior change (was Re: Boost.lockfree)

6 Oct 2015

      On 6 Oct 2015, at 11:38, Andrey Semashev  wrote:
...
On Tue, Oct 6, 2015 at 12:31 PM, M.A. van den Berg  wrote:
...
On 6 Oct 2015, at 11:17, Andrey Semashev  wrote:
...
On Tue, Oct 6, 2015 at 11:56 AM, M.A. van den Berg  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.
No, it's more than just poor-man's versioning. The key point is that
Test, Test2 and Test3 are different libraries that are maintained
separately (from the user's perspective) and can be used side by side.
If a library or user's code sticks to C++03 for whatever reason, it
can keep using Test and receive updates for it in a timely manner.
This is not achieved by simply having different versions of Test
available for download, even if multiple versions could be somehow
used together in a single build of Boost or user's application.
Yes I agree, that’s orthogonal to versioning then.

If a library was published with an implicit prerequisites/promise that it compiles on C+03 then that’s something you shouldn't break. You can decide to no longer maintain it, but actively breaking backwards compatibility without the users having the ability to downgrade (a subset of libraries in boost that break backwards compatibility for them) is horrible for users.