From: Jeff Garland (jeff_at_[hidden])
Date: 2006-01-30 22:32:38
On Mon, 30 Jan 2006 18:48:10 -0800, Thomas Witt wrote
> several recent posts touched the issue of deprecating compilers in
> the next release.
> Given the fact that we don't even seem to know what deprecating
> means I would like to propose the following:
> Compiler support should be phased out instead of dropped. I see
> three different stages here.
> Fully Supported
> Libraries should make an effort to support these compilers.
> Regressions in support version to version should be avoided. (Weasel
> wording intended). Full regression testing.
> Marked Deprecated
> No effort is required to support these compilers in new
> functionality. Version to version regressions are accepted after the
> first version that marked these compilers as deprecated. Full
> regression testing (if resources are available). One key idea here
> is to give the user a good idea on the level of available
> functionality until a toolset reaches the "Unsupported" stage.
> No regression testing is done. (Library authors might still support
> these toolsets for their libraries on a case by case basis.)
> AFAICS there seems to be strong support for moving gcc-2.95 and vc6
> to "Marked Deprecated" and somebody needs to fight Alisdair over
> (volunteers? any?).
I like your breakdown although we might need another category like
'experimental' to describe newer compilers that are partially supported or
might be supported in the future -- although maybe it's the same as unsupported.
Anyway, here's how I'd categorize the current set of compilers on the
I know -- that's a pretty aggressive cut in supported compilers, but I think
it's time to let boost developers focus on new libraries instead of porting.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk