[boost] proposal - introduce API & ABI compatibility guidelines

[Stefan Seefeld via Boost]

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

[Artyom Beilis via Boost]

On Sun, Jun 18, 2017 at 9:18 PM, Stefan Seefeld via Boost

Post by Stefan Seefeld via Boost

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Brian Wood via Boost]

Post by Artyom Beilis via Boost
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.

I'm only comfortable using Boost in private/closed source applications.

I think on line code generation will help with some of the packaging
problems discussed in this thread.


Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost