Release 47 went out today with animations support. This new feature will need testing - so let me outline how test builds work here at Scirra. It's similar to how the stable and unstable releases worked with Classic.
Test builds
When we release new features, they need extensive testing to make sure they work. Unfortunately, being the tiny startup we are, we don't have the resources to do testing the traditional way. The traditional way is to write hundreds or even thousands of test programs that automatically check everything is working. Usually there's a whole team of people dedicated to testing full-time. Since there's just me, that's not really on the cards. Instead, we're releasing test builds, which basically mean "there's new code here, and we hope it works but it hasn't been proven yet - try it out and let us know how it goes!". Test builds include the latest bleeding edge features and updates, but using them comes with the risk that you might be more vulnerable to bugs and crashes. We try hard to make sure it's stable and correct, but we're only human, so we can't expect it to always be perfect on first release. Test builds have "Construct 2 (test build)" in the window caption.
Checks and check failures
While developing Construct 2, I put in to the code hundreds of testing checks (assertions, to programmers) that basically check that everything is going to plan. If one of these checks fails, it means something has probably gone wrong. Usually, these checks are only used internally, and are removed when making a public release. However, one of our tricks is to leave these checks enabled in public test releases. This means if something does go wrong for you, hopefully - not all the time, but most of the time - you'll get a special "check failure" dialog. This will be loaded with technical information which isn't very useful for you - but if you copy-paste it to us while making a bug report, it's invaluable. Normally when software fails, it just crashes and Windows tells you it closed the program. With a check failure, often the problem is immediately obvious from the information provided. The info includes the source code file, line number, a small description and several other things that make life insanely easier to tell what went wrong instead of "it just crashed"! With the information in check failures, we can fix bugs much more quickly and more reliably, resulting in a much better Construct 2 for everyone.
Stable builds
We're still very early in development so all of our releases are test builds. However, in future, once a test build has been thoroughly used and debugged, we'll then release a stable build. This has all the checks turned off, so you'll never be nagged with technical jargon. Another small bonus is they run slightly faster, since they're not running all those checks.
Which should you use?
Right now you have no choice, because there are only test builds, har har :) But seriously, once we have stable builds regularly going out, you have a choice: use the latest test builds, or stick only to stable builds. Crashes and bugs should be much rarer in stable builds, since you're using well tested versions of Construct 2. However, you can get your hands on the latest and greatest features as they happen by using test builds. Also, it helps us make Construct 2 better! So it's up to you, but we like it when people take test builds for a spin.
The overall effect
I'm certain Construct 2 is far more stable than Construct Classic, and I'm sure the way we do checked test builds has a lot to do with it. I'd definitely recommend it to other software developers. It's a little unusual for you, the user, to see these obscure popups occasionally, but I can't tell you the massive difference it makes in coding. Many a time with Classic I'd spend hours debugging and pondering over a user who reported a "crash". with Construct 2 and a check report, often the solution is immediately obvious. It's a massive time saver. So I hope you don't mind being guinea pigs for the time being - I have to say it's working great :)