Let us say that a Boost user wants to find out if Boost library, for the latest Boost version, supports a particular compiler/version which he is using. He goes to the main Boost page in his HTML documenation for Boost and looks to find this information. It is reasonable to assume he looks under the Documentation link, although I personally think that a specific link, with an explanation about the information for which he is looking, on the main page should direct him to such information since it is of primary importance to Boost end users to know this. In the documentation page there is nothing on top which immediately tells him this information. When he scrolls down he sees the line which says, "See Compiler Status page to find out what library works with which compiler." So he clicks on this link. A very nice page of explanation, among its excellently written information, directs him to the Compiler Status Summary, and he clicks on this link. On the compiler status summary page he is met with links for a Developer Report, User Report, Inspection Report, and License Report and a general summary of compiler pass/fail rates on the Linux platform, which is dated 17 months ago. This is pretty poor, not only becaause it implies that Boost only support Linux compilers and the general report is from 17 months ago, but also because he has no idea what each of the links means. But let us suppose that he is undaunted and decides to click on the User Report, since he is an end user. The user report regression page is now shown and he clicks on one of the links in the list to his left to see the regression tests for that library. Let us suppose it is Boost smartptr, but it could be any library. He now looks for the compiler he is interested in among the header groupings. For the current release, on Windows, he sees Borland 5.8.2, Borland 5.9.0, msvc 8.0, intel-win 9.1, msvc 7.1, cw 9.4, intel vc 7.1 win 9.1, and msvc 8.0 wm5. He then assumes, quite reasonably, that if a specific compiler is not on this list, it is not supported in the latest release for the particular library. So evidently VC 6.0, VC 7.0, various forms of gcc, and the latest release of Comeau are not supported by any libraries for the latest release. But wait, he noticed on the Boost main page that gcc 3.4.x, vc 6.0 ( and 6.5, ie SP5 ), and vc 7.0 are supported for the latest release. So he assumes that regression tests have not been run for these compilers on Windows. Let us suppose by some quirk of fate, and the contingencies of his job, he actually has to work with on of these compilers. He now goes to the documentation for the library he is interested in, let us say smartptr again, by going back to the general Boost documentation page and clicks on smartptr. There is nothing there, as he suspects, that is going to list what compilers are supported by this library in the current release. This will generally be true for any Boost library, so I am not picking on smartptr. Now he does not know, other than by trying to actually use a Boost library, whether that library actually works with the compiler he is actually using. Finally, let us suppose by an equal quirk of fate and the contingencies of his job, that he is not using the latest release of Boost but must use an earlier release. Here the documentation for the earlier release contains no regression reports at all for that release but only for the latest release. So for any other release it is impossible to determine whether a particular compiler/version is supported by a particular library. I do realize that the config system in Boost will often tell the end user whether his compiler/version is supported in general for a particular Boost release when he tries to use it. But it does not tell the end user, in the case that the compiler/version is generally supported by the config system, whether or not a particular library supports his compiler/version and, if he can not find the results in the regression tests or in the particular library's version, it becomes difficult for him to determine. I do not think that the situation I have outlined here is good for Boost from the end users perspective. The typical end user, when wanting to use a particular 3rd party library whether of Boost or otherwise, wants to know immediately, before any other action is taken, whether that library supports the compiler/version he is using. I believe Boost should make it both much easier and always possible to determine whether a particular compiler/version can be used with a particular library in a particular version of Boost without the end user trying to use a library and, if he can not, encountering compiler errors. He may not know, even from compiler errors, whether or not the errors are his own or simply because the compiler is not supported for that library. This is not a criticism of Boost in general and certainly not the excellent smartptr library, but instead it is an effort to get Boost to create some easier system by which end users can determine whether or not they can use a Boost library in the particular working situation in which they find themselves.