On Mon, 30 Jan 2006 18:48:10 -0800, Thomas Witt wrote
Hi,
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.)
AFAICS there seems to be strong support for moving gcc-2.95 and vc6 to "Marked Deprecated" and somebody needs to fight Alisdair over Borland (volunteers? any?).
Comments
Thomas
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 regression page: Supported; vc7.1 vc8.x intel9_x cw9_4 gcc3.x gcc4.x tru64cxx71-xx Deprecated: intel8_x tru64cxx65-xx Unsupported: borland 5_6_x cw8_x dmc gcc2.95.x sunpro vc6 vc7 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. Jeff