David Abrahams wrote: > Aleksey Gurtovoy <[EMAIL PROTECTED]> 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 perform > > 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. Aleksey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost