Hi,
Bugs in newly added code cannot be regressions.
Similarly, if we add a dll and some app starts using it and breaks, technically that's not a regression even though the behavior got worse, because it has always been broken, it just wasn't exercised before.
What does this distinction bring us? The old definition, "if it worked in version N and doesn't in N+1, then it is a regression" was straightforward and easy to understand. There was little to debate, no room left for confusion. Every such regression could be associated with the SHA1 of a commit.
The new definition can get arbitrarily complex. Consider bug #19496. Bug resolution likely involves moving from mciwave to mciavi. As mciavi is not equally advanced, this move will likely cause bugs to appear in other apps. But we wouldn't call them regressions "because it has always been broken"?!? That makes no sense to users.
What benefit does it have for developers? Having one's name appear less often in source.winehq.org/regressions when doing The Right Thing (TRT)?
Regards, Jörg Höhle