Jeff Garland wrote:
Gennadiy Rozental wrote:
I must say I feel very similar.
I believe Bemans approach is way too pessimistic. And kinda deminishing to the configuration he has no direct access to ;) How VC 8.0 failure is more critical than let's say gcc on sparc solaris? Assuming that both have similar tester resources.
They haven't typically had similar resources. We've usually had 2-3 VC 8 testers and maybe one gcc on solaris.
What I beliee we need is more objective criteria for what is "release compiler". Specific requirements to number of testers and testing turnaround time comes to mind.
Instead of getting bogged down in trying to define requirements, I think we should simply agree on a the 'primary platform list' (essentially what Beman is doing). Don't think of this list as release compilers, just a good cross section of the platforms that provide a) good testing support and b) high standards compliance -- thus minimizing the typical hackery needed to port to this compiler. Again, no compiler/platform is being excluded from testing and we want library authors and people with an interest in a platform to continue to port at their discretion -- but I hope by now we'd all agree that bugging authors of new libs to port to VC6 and holding the release is a bad policy because it harms more users than it helps.
From an end user's perspective I think it is really important, for a given release and library of Boost, to know whether or not a particular compiler is supposed to work for a particular library. The regression tests do not, unfortunately, always give the end user that information. While I understand the concern for getting out timely releases of Boost which are guaranteed to support a subset of highly conformant compilers, this way of doing things will only make it even more difficult for end-users of those compilers which are not part of that subset to determine whether the latest release of a particular Boost library is supported when using their compiler.