I've found that this doesn't have to be the case. Continuous deployment is a good example where this doesn't hold. You roll out things more quickly... and you

I've found that this doesn't have to be the case. Continuous deployment is a good example where this doesn't hold. You roll out things more quickly... and you experience less issues! When issues happen, the cause is easier to isolate. After all, you only had one day's worth of changes (and not one year's worth). The previous state is more knowable. Testing is more concentrated. Apple's new OS releases are the opposite of this. They release 30 different major changes at once, they all collide, and we end up just assuming that .0 releases will be broken. In an alternate universe, Apple just releases updates to parts of software when it's ready. They don't pin Safari to the OS (because there's not much of a technical reason to). They could pinpoint _when_ "Month 13" started showing up everywhere beyond "when everyone downloaded that 7 gig update". It takes some effort and tooling, but if you're expecting to make changes, a lot of times making the changes piecemeal will mean that post-release stability will increase in many cases.