Jeff, Jeff Garland wrote:
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.
See below.
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
FWIW we just added QNX to this list.
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.
Hmm… our disagreement might be mostly about terminology. First of all I was never really happy with the category names but I failed to find better ones. Thinking about it again. The reason might be that we have to deal with two different issues when we talk about compiler support. The easy part are outdated compilers. For those it's easy to say we don't care (that's basically the meaning of unsupported and also in some way for deprecated). The hard part are compilers that just aren't compliant enough to support all of boost without heroic efforts by library writers. This category of compilers is the reason for the weasel wording used to describe the fully supported category. The intend is to say we make a reasonable effort, document the limitations and provide regression tests until these compilers reach the unsupported stage due to obsoleteness. As far as your list of unsupported compilers goes. I do feel uncomfortable with just dropping most of them without first deprecating them. This does not mean we should put effort into improving support for them 1.34 we just should not break them incidentally. As far as sunpro goes I'd like to see that one in fully/partially supported. Thomas -- Thomas Witt witt@acm.org