<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 30, 2014 at 9:19 AM, Dylan Baker <span dir="ltr"><<a href="mailto:baker.dylan.c@gmail.com" target="_blank">baker.dylan.c@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Although it hasn't been nearly as bad recently as it was before we<br>
started writing unit tests for the framework we still do have<br>
regressions, especially when refactoring touches the API's. I know that<br>
IGT integration was broken until recently, and I suspect that if we<br>
looked several other suites are broken.<br>
<br>
While I think this is a good idea, it's a lot of work and it will<br>
probably be disruptive for a lot of developers, and a lot of work. So<br>
it's not very high on my list of priorities.<br>
<br>
However, I'm not convinced that having versions of the tests themselves<br>
is all that useful.<br>
<span class="HOEnZb"><font color="#888888"><br>
Dylan</font></span><br></blockquote><div><br></div><div>I agree that applying version information to the tests is also not very useful. However, I do think that it is extremely useful to apply version information to the results files themselves. This can be useful in the fact that it will allow an easier method to detect outdated test results. I believe it is not a good idea to compare results from a test run from about 5 years ago to a test run that was made just last week. There is too many changes in the results file themselves over the past couple of years that it is nearly impractical to keep a test result map from that time period. At least with quarterly releases we can add a flag ( version number ) in the file that will indicate that the test results are not compatible between the two files.<br></div></div></div></div>