Vladimir Prus wrote:
Well, (a) is non-verifiable, and (b) is hard to achieve (e.g. you cannot check "in no way worse" for toolsets that are not tested, and "no way worse" might include non-testable things.
OK I'll rephase a) When the library is as good as the author THINKS he can make it b) This is easy - when the number of regressions is less than before the change or there is an improvement and no new regressions. re b) Naturally, there can be no regression for a compiler that has never been tested.
So, we only have test results for trunk and release branch, and have to decide of merge from trunk and release branch is OK. All I'm asking is whether, assuming I'm otherwise willing to do the merge, if I can arrive at this "OK/not OK" decision without any manual investigation and comparison of test results?
Hmmm - b) requires some manual investigation / comparison of test results. So I would still recommend b) for improvements and a) for new libraries. Robert Ramey