proposal - introduce API & ABI compatibility guidelines
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...
On Sun, Jun 18, 2017 at 9:18 PM, Stefan Seefeld via Boost
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
participants (2)
-
Artyom Beilis -
Stefan Seefeld