So the main difference between public builds and daily builds is the amount of testing that goes on vs. access to new features and bug fixes.
For public releases, we freeze new features and normal bug fixes for a couple of weeks and test the release candidate against our various test apps on as many devices as we reasonably can. If we find bugs in this testing period that were not present in the previous public release, we will fix those. We call these regression bugs, meaning a bug we introduced since the last public version. We never want a new public version to go backwards where possible.
In the time in between, we work on filed bug reports and adding new features. The amount of testing daily builds is fairly limited (just because it takes our full team a couple of weeks to do full testing, we would never get daily’s out of that was the case). For bug fixes, those generally make the builds more solid. For new features, sometimes issues are discovered that need fixed and are generally fixed in the next couple of daily builds. Many people release apps with daily builds. Others feel more comfortable staying with public builds.
One of the things that affects this is that Apple and Google Play are moving targets. You could have not updated Xcode to 9.3 (though the Mac App Store likes doing that for you) and stayed with the public release. When Apple does this, we have to add support for it and we **cannot** go back and patch older builds. Additions and fixes go into dailies which get rolled into the next public.
So you can use daily builds for releasing though we suggest you test your app very well before you release it to your customers to make sure something didn’t break. And if it’s a beta feature (like HTML5 currently is), you should spend extra time testing before you release with it.
As for when our next public release will be, we don’t publish dates because the community has a bad habit of turning estimates into hard dates. Public builds are generally released every four to five months. It’s frequently determined by the number of features and bugs fixed or when upstream vendors like Apple make a breaking change (like not being able to submit due to a change). Since you can fall back to 9.2 (or have both installed), that’s not really a breaking change.
Now all that said, Google Play has changed something with their Google Play libraries on Android and its generating a lot of crashes. There are also a lot of audio related crashes on Android that Google is reporting with more frequency. Those Android audio changes are in beta now and we have to finish all of these Android crashes before we can release. We want to bring HTML5 to a release status too, so our team is very busy trying to get to a point where we can put out a new public release in a timely fashion.
Rob
