Re: [boost] Permanently retire VC++ 6?

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-12-06 12:55:56

David Abrahams wrote:
>Brian Allison <brian_at_[hidden]> 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? 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?

==> Therfore, it would be reasonable to officially support the most recent 
version and the one previous.

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. 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.

- Reece