"Reece Dunn" <msclrhd@hotmail.com> writes:
David Abrahams wrote:
Brian Allison <brian@dtmr.com> writes:
But how would it change anything? We don't "guarantee" anything today, and I'm pretty sure we won't guarantee anything a year from now either.
The problem is that as you make it more precise, you also make it clear that it's not very meaningful. Even most compilers we'd consider to be "quite conformant" are not without their issues. So, I'd like to see some way of formulating this so that we can all understand what it really means for:
users library developers testers (anyone I left out?)
Ok. Here goes...
== Users ==
There are two categories of users: (1) those who are supporting legacy code bases that rely on or use old compilers (e.g. VC6); (2) those who are flexible about what compiler they use and move to either the latest or previous release of a compiler (e.g. VC7.1 and VC8).
The main compilers in question here (disregarding Borland for the moment) are VC6 and GCC2.95.x. Now that MS have dropped support for VC6, should Boost do the same?
Good question. I'm trying to ask you: ** what would doing so mean for users? **
GCC2.95 is 2 generations old (GCC3 and GCC4 have been released, with GCC3.0 being in the field for some time now). Given that, are there any users that still require GCC2 support?
Good question. ** what is GCC2 support? ** ** what would withdrawing it -- assuming we currently offer it -- mean for users? **
==> Therfore, it would be reasonable to officially support the most recent version and the one previous.
I'm trying to ask you: What would making that decision mean for users library developers testers
The next question is what compiler vendors should be supported...
I think the most popular/used compilers for a platform should be supported: 1. GCC on Linux; 2. GCC and CodeWarrior on Mac; 3. GCC and VC on Windows.
I know that this is not a complete picture. Other compilers can be added that are viewed as critical for a given platform. This then gives the core set of compilers that need to be supported.
== Library Developers ==
Other compilers that are not on this list, but are reasonably conformant (i.e. above 90%) should also be supported.
I'm trying to ask you: What would that mean for library developers? For example, are they required to make their libraries work on those supported compilers? Would they lose the ability to see test results for unsupported compilers? etc. Please expound
Boost doesn't require a library to support broken compilers, so motivation for support here would come from users that target those compilers. The question then becomes how broken should a compiler be before it is not supported. This is blurry and is mainly up to the library developer and how much effort they are willing to spend supporting those compilers [*].
[*] This effort is in terms of finding a workaround, testing that on the target compiler and on other compilers to see if there aren't any regressions. This can be difficult if you don't have access to the compiler/version in question. This may mean cooperating with others in the group who do have access to those compilers, although this can be difficult if the library is in a state of flux and is changing from day-to-day (synchronising effort between you and the Booster who is helping you).
== Testers ==
This is down to how many resources a tester can put into running the tests. It takes a reasonable amount of time and hard drive space to run the regression tests *per compiler, version and platform*. I know that this is distributed across several testers, but there are only a few core testers that run the tests frequently. It also costs money and effort to set up a new compiler/version.
How is that any different from today? As far as I can tell, you failed to address my core question. What does making some compilers "supported" and others "not supported" mean for our process, our developers, our users, and our testers? -- Dave Abrahams Boost Consulting www.boost-consulting.com