Boost logo

Boost :

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2006-01-31 06:49:17

Thomas Witt writes:
> 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.
> Unsupported
> -----------
> No regression testing is done. (Library authors might still support
> these toolsets for their libraries on a case by case basis.)

We can't actually _prevent_ somebody from running regression tests for
an "unsupported" toolset, nor do I think that we want to. I'd say if
one has the resources to run the tests and interested in seeing /
posting the results (however pitiful), they should go right ahead. IMO
"unsupported" status just makes an individual developer's decision to
ignore these results uncontroversial.

Aleksey Gurtovoy
MetaCommunications Engineering

Boost list run by bdawes at, gregod at, cpdaniel at, john at