"David Abrahams" <dave@boost-consulting.com> wrote in message news:ulktgbcqp.fsf@boost-consulting.com...
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> 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