Sorry to step in with an answer as well, but I thought of replying also from the perspective of a tester. I’ve been working with coders for the past 5 years on many projects so I can compare, and I’ve rarely seen the quality the VCMI team is able to deliver (considering the manpower) elsewhere.
As Tow already replied, they do check, but it’s not the task of the coder to run exhaustive tests. If they did that, we (the testers) would become redundant.
The best product a coder can deliver in the development phase (where we are now), is a built which has low chance of containing major bugs/crashes, and that the VCMI team has managed to provide every time.
Tow, who prepares the package for the new release, could probably spend 10 times more time in testing the final package before making it public, and still not spot some major bug, simply because it may not show up on his machine, or because it’s triggered by one of the (maybe) 100 actions one or another may label as “basic” in the game, the very action which leads to that bug (which can be indeed a very ugly, unavoidable bug).
That aside, the timing for this release was maybe not the best (for me at least). So far I managed to be around the last several releases to hunt such major bugs (and there were a couple of times when I found some and they corrected very fast). But I’ve been very busy lately, on top of which I also had some issues with the computer which were solved only this week-end.
But, as Tow said, just tell them (here or on Mantis) what are the major bugs which slipped in. I’ll try to have a look as well myself to see which are the biggest issues, but prolly won’t happen before the week-end (haven’t installed any game yet since the system restore; Heroes will be first, but I don’t have time the next few days).
90% of the time we actually have “Fixed in…”. Quite rarely I see a “Probably / should be fixed in…”, and that usually happens when the code changes were more complex and would require time consuming tests to actually confirm the fix. Instead of “I was too lazy to test my changes”, a more productive way for us testers to translate that “probably fixed…” would be to see it as a short version of “Dear tester, the fix seems to work fine on my machine, but due to the complexity of the issue, the random reproducibility or the fact that I couldn’t reproduce the original bug in the first place (but figured based on crashbug what could have been), could you kindly check on your machine if it’s still there, so that I can better use the rest of my time to correct other bugs?”
@Boulie: Please don’t take the above in a bad way. I meant only good. I can understand that as tester one may be tempted to get frustrated if the dev version looked okay, while the official release actually has more bugs, but I wanted to point out it’s often just a matter of expectations and interpretations.
Cheers,
Zam