From a business perspective it's because we do something called continuous delivery (the CD in CI/CD) where we choose to prioritize shipping regular updates. On

From a business perspective it's because we do something called continuous delivery (the CD in CI/CD) where we choose to prioritize shipping regular updates. On most websites this is happening constantly behind the scenes, for apps we actually have to ship artifacts somewhere and get them to update. Some people choose to tell you when an update happens or give an option to decline it, others do it silently in the background. There are a lot of reasons why, from operational (it's easier to develop quickly and get more revenue when you can ship updates daily/weekly to acquire new customers or reduce churn rather than postpone releases over long cycles and ask people to wait) to functional (if there's a security flaw that exposes you, my user, i want the software patched as soon as possible). The big reason (to me) is an organizational one - it shortens the cycle time of code churn to QA to bug report to fix. When you stretch out release cycles that typically means you're doing feature/code investment up front, then bulk QA, then bulk bug fixes, then bulk QA (usually mixed with scope creep). With CD you just have tickets, they get moved to review/QA, the feature gets shipped, you pick up the next ticket. In a good workplace it's legitimately hard to have crunch time close to major deadlines because it's a lot less risky to delay a feature until a future release when that date is next week and guaranteed. From a business perspective the advantage is that you can resource plan more effectively (you can forecast customer acquisition/churn much easier when there's constant feedback, therefore you can predict revenue cycles better, and you can also move people around a lot easier to hotspots with the highest priority). That's basically impossible with staggered releases because you're not getting input from the market on what you need to do to make more money and spend less. There are obvious downsides, nagging aside. If it's easier to ship it's easier to ship broken things and half done things. And you can do things to make it more valuable to users like option updates to main and nightly/beta/security release channels. But those cost time and money to build and maintain and are kind of a nightmare for non tech-savvy users where using "nightly" to get the latest and greatest is a non-starter, and optional updates equal no updates and getting the same bug report in the queue for years. So some businesses don't do that. It's such a big deal to me that when I interview I ask something like "when was your last release and when is your next one" to see if they actually have CD. As a dev you don't want to work in an environment where there's some long away deadline for release, that sucks.