Re: [boost] proposal - introduce API & ABI compatibility guidelines

Subject: Re: [boost] proposal - introduce API & ABI compatibility guidelines
From: Artyom Beilis (artyom.beilis_at_[hidden])
Date: 2017-06-18 19:55:28

On Sun, Jun 18, 2017 at 9:18 PM, Stefan Seefeld via Boost
<boost_at_[hidden]> wrote:
> Following up on this point made by Peter Dimov in another discussion:
>
>> This is part of the price you pay for being accepted as part of Boost
>> - the duty to act as an integration test for your Boost dependencies.
>> This is beneficial for you in the long term, because you can detect
>> breaking changes in your dependencies before they get shipped. If you
>> only test against 1.56, and 1.64 breaks your library, you won't hear
>> about it before 1.72. This does you no good, and it does your users no
>> good. You WANT to know if changes in 1.65's SmartPtr would break you
>> BEFORE 1.65 gets released.
>
> The real problem that you are touching here is Boost's lack of any sort
> of ABI or even API stability. So Boost 1.X and Boost 1.(X+1) are two
> distinct packages, as there is no metric that enables even to measure
> the amount of incompatibility between the two. Any normal library that's
> used in-production would have strong requirements for backward
> compatibility, to enable users to reason about the risk of upgrading etc.
>

The is one of the major Achilles' heel of Boost
(along with attempt to make **everything** home build from
build system, testing system to docs generation)

Boost breaks API all the time. Even withing same release ABI may be
changed just by small define - of course don't even try to use
C++03 and C++11 in different parts of projects.

It makes virtually impossible to use Boost in libraries that
want to keep any kind of backward compatibility of API or ABI.

The problem is that it isn't going to change in near future because
it is almost impossible to reach a consensus of some strategic
direction because any major change will find enough developers
who will not want one.

So today I use boost only in applications and never in libraries.
Finally C++11 included most critical parts needed from Boost.

Artyom