Boost logo

Boost :

Subject: Re: [boost] Deprecation Policy
From: Peter Dimov (lists_at_[hidden])
Date: 2015-05-18 07:00:56


Stefan Seefeld wrote:
> To reiterate my proposal:
>
> Let's try to modularize boost libraries to the point where they can be
> developed, built, and released individuality.
> Let's try to provide backwards compatibility guarantees such that users
> may swap in new versions of a library without fearing failures (either at
> compile time nor runtime).

To repeat myself, I don't think that people calling for independent library
releases appreciate the hidden benefits of the current release approach.
These are taken for granted and only the problems are visible.

It obviously depends on the library, but many Boost libraries are highly
interconnected. It will not be any fun if every user had to discover for
himself that for X 4.1, he needs to use Y 2.7 or higher but lower than 3.0,
which requires X 5.2 or above.

As for providing ironclad backward compatibility guarantees, this, too, is
somewhat optimistic. Based on my experience - which may be somewhat skewed -
I can quite confidently state that there is no change, however minor, that
doesn't break someone's code.

I am no fan of monolithic releases, but we need to have a clear
understanding of what they bring to the table. Specifically, the current
release approach is a guarantee that the library versions in a release have
been tested with one another. It serves as an integration test,
complementing each library's unit tests. Breaking changes in a Boost library
are often discovered when another Boost library breaks.

That said, I do think that releases should be made less monolithic. It
should indeed be possible for people to swap in a new version of some
library. This requires libraries to be confined to their own directory in
libs/ (as they are when using Boost from Git.)

Specifically, this would entail retaining the include/ directories, doing
"b2 headers" on install, and decentralizing the documentation. The virtual
include directory created by "b2 headers" is going to inconvenience people
who like to put the whole boost-1.x.y/ into version control, but such is
life. On the upside, more modular releases ought to be easier to do.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk