Re: [boost] [filesystem][program_options][serialization][test] fromcomp.lang.c++.moderated

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2006-05-10 14:50:35

David Abrahams wrote:
> "Ames Andreas" <Andreas.Ames_at_[hidden]> writes:
>
>>>   fluidity
>>>
>>>     "frozen" == Only bugfixes, in principle.  A library can move out
>>>     of "frozen" to stable at the whim of its maintainer.
>>>
>>>     "stable" == Only bugfixes and extensions.
>>>
>>>     "active" == backwards-incompatible changes avoided with extreme
>>>     prejudice, and made only after one release of deprecation.  A
>>>     strong bias is given towards preserving availability of old
>>>     interfaces under the same name, even if they've been superceded
>>>     by newer ones.
>>>
>>>     "fluid" == whether we should have such a category is open to
>>>     debate.
>>
>> Sounds like a lot of work for the maintainers and the release
>> managers.
>
> I can't imagine why that would cause any work for release managers,
> and speaking personally, I wouldn't find classifying the fluidity of
> my libraries to be much of a hassle; it shouldn't take more than a few
> minutes.  Changes in fluidity happen rarely, and frankly, I think
> choosing and publicizing categories would help me focus my maintenance
> decisions.
>
I agree.

The "core/optional" distinction is more difusee, too much to be usefull 
perhaps, but this fluidity "tag" is a simple and good idea.

As you and others pointed out backward-incompatible changes should be 
avoided real hard, and their impact studied and announced very carefully in 
case really needed.

One should always consider branching a "new" library instead of breaking the 
version users are currently using.

Also, at least for leaf libraries, like serialization, the mantainer can 
keep the old version in sync with latest boost. This way, users don't need 
to stick to an older "version of boost" (as a whole) but only to an older 
"interface-version" of a specific leaf library.
That is, users could install the lastest boost and then "override" a leaf 
library with an "older-but-up-to-date" version of it.
"older-but-up-to-date" means a library that is kept in sync with all of 
boost but which exposes an older interface.
Of course this is not needed if the library interface evolved in a 
backward-compatible way.

-- 
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com/