From: David Abrahams (dave_at_[hidden])
Date: 2003-08-12 08:46:20
Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
> David Abrahams wrote:
>> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>> >> I worry a little about requiring library authors not to regress on
>> >> compiler combinations they don't test with.
>> > Well, the regressions are run daily, so testing happens. Another
>> > question is whether library authors care about how their libraries
>> > on all the compilers the regressions are being run on.
>> > Obviously, some compilers/configurations are included in the regression
>> > testing because the ones who manage the latter are the ones who are
>> > most interested in those. Then, again, obviously, some compilers/
>> > configurations are included in the regressions because they are very
>> > widely used.
>> > For every release, the interested parties include library authors,
>> > regression runners, the release manager, the maintenance wizard, and of
>> > course active users who are subscribed to either of the lists.
>> > Given the above "setup", the implied interests of the participating
>> > groups, and their explicit and implicit responsibilities and gratitude
>> > towards each other, I think striving for "no regressions" goal I stated
>> > above would be both a reasonable and fair strategy which can be made to
>> > work.
>> Some people are posting regressions for pre-release compilers. Should
>> a library author should be expected to keep his library healthy on
>> some weird/broken compiler just because it happened to work there by
>> chance at one point?
> You skipped the part of my original posting which explicitly said:
>> > While I totally support the failures markup goal, I would like to see
>> > _the_ release criteria to include "no regressions from the previous
>> > release" item as well, preferrably for all non-beta compilers that are
>> > currently under regression testing. Especially since now we have tools
>> > to ensure it.
Still, lots of weird/broken compilers are non-beta. IMO all the
Borland tools fall into that category. Lots of people consider
supporting older versions of released compilers to be unneccessary.
I don't always agree, but for example I recently dropped CWPro7
support from Boost.Python, IMO with justification.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk