I think it's simple to understand the straightforward reasoning that's most likely at play:
- Apple has a schedule set FAR in advance
- That schedule already has built-in gaps between the developer release and public beta release that err on the side of caution (bigger gap with the earlier betas, when things are more unstable, and smaller as we get closer to release, as the "risk" of running a beta naturally decreases)
- If something goes wrong with a developer release (like when we see things pulled, for example), Apple changes the pre-set schedule to account for the curveball
- If there are no major showstoppers, security holes, exploits, etc are present...they stick to the existing schedule, and the pre-set, existing gaps remain
All one needs to do to grasp this rationale is to let go of the idea that Apple is making "game-time" decisions about when to release what, based on real-time reports, like "oh, this one seems good, lets push the button". We joke about that in this thread, for good reason—it's not how it works.
From the outside it seems clear to me that they will move releases
back if their hand is forced, but will not move a release
up, regardless of feedback/reports.
Sucks for us chomping at the bit to be on the bleeding edge, of course, but totally makes sense from a risk/reward, prudent software management perspective. They're no incentive for Apple to move things up, just to satisfy us excited-to-use-the-beta users. The smart thing to do is minimize the amount of variables (like a feedback-dependent release schedule in any case other than an emergency).
When you have an install base of over 1 billion, you're going to be conservative about such things, especially early in the beta cycle.
