Boost logo

Boost :

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-05-05 23:08:31


"David Abrahams" <dave_at_[hidden]> wrote in message
news:ulktgbcqp.fsf_at_boost-consulting.com...
> "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:
>
>> I do not agree it's proper way looking at that. IMO "deprecation"
>> has nothing to do with library itself. What it has to do with is
>> what you test a library on.
>
> Sorry, you've all got it wrong :)

I think we just having terminology misunderstanding.

> Deprecation indicates an intention to stop supporting a particular
> construct or usage, sometime in the future.

You may refer to "feature/construct deprication" in relation to a library
functinality. You may refer "compiler deprication" in relation to set of
compilers/configurations a library is tested on. You may refer to "support
deprication" in relation to set of compilers/configurations supported by a
library. First and third kinds managed excusively by library authors.
Second - by the fact which compiler boost performed testing on.

> Deprecation is not a dead end. It is a good thing, because it allows
> us to break code in the service of better libraries, by giving users
> fair warning. Whether Boost as a whole can deprecate the use of a
> given compiler is another matter.

 Here we agree.

Gennadiy


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