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

From: David Abrahams (dave_at_[hidden])
Date: 2005-12-06 14:29:41

"Reece Dunn" <msclrhd_at_[hidden]> writes:

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

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