[boost] proposal - introduce API & ABI compatibility guidelines

Subject: [boost] proposal - introduce API & ABI compatibility guidelines
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-06-18 18:18:21

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.

Thus, to follow up (and not pollute the original discussion about
modularization), I'll propose the following:

I'd like to see guidelines to be established for:

* what API and ABI changes may be applied in a given release

* have a clear definition of version numbers (major, minor, bug fix)
with associated semantics

* impose testing requirements to enforce the above.

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...