Re: [boost] Deprecation Policy

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.