Re: [boost] Deprecation Policy

Subject: Re: [boost] Deprecation Policy
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-05-20 15:21:36

On 19.05.2015 01:29, Stefan Seefeld wrote:
> On 18/05/15 02:56 AM, Vladimir Prus wrote:
>> On 5/17/2015 4:08 AM, Stefan Seefeld wrote:
>>> 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).
>>
>> Stefan,
>>
>> could we start by agreeing that not every set of C++-level components
>> will actually benefit, in a cost/benefit sense, from separate
>> development and release? Say, Qt has a few libraries, but has monolithic
>> release. It might be possible to permit QtGui 5.N+1 to work with
>> QtCore 5.N, but the effort and alternative cost of doing so would
>> greatly exceed any benefit.
>
> Sure, fair enough.

Good, thanks!

>>
>> If we agree on that, then maybe it would be better to propose
>> specific boost libraries that should be released individually, do
>> that, and see whether users appreciate the benefit? That seems
>> more practical than a blanket statement about all boost libraries.
>
> OK, that's a good suggestion. So, as I'm trying to get back into
> Boost.Python, I'm considering decoupling that from the rest of Boost. I
> think this is an obvious first candidate, notably because it's a
> substantial library (not header-only) that few other Boost components
> depend on.
>
> Any thoughts on that ?

That's certainly sufficiently local in scope that it could be done.

The only concern is that I'm not sure there are many users who need very
current Boost.Python, and older Boost. Do you feel there is a demand?
Or it's merely that you'll find it more convenient for yourself?

-- 
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com