Unfortunately, the 'continuous upgrades in the background' model removes the user's choice of when to upgrade. In some cases, I want to stay on an older versio

Unfortunately, the 'continuous upgrades in the background' model removes the user's choice of when to upgrade. In some cases, I want to stay on an older version because a new release breaks compatibility with plugin X, or upgrading would require me to change a workflow that is working well, or because I have muscle memory built around the UI of the existing version, and I don't have to think when I use the app. If an older version still gets security and bug fixes, then I might only upgrade when the benefit (new features and improvements) outweighs the effort/cost required to adopt the new version. It also encourages frequent, fad-driven UI refreshes, and this is worst seen with web applications like Facebook and Gmail. Every so often, Google Maps plays hide and seek with the terrain view button. Sometimes, stability and a slower release cycle (while still providing timely security updates) is good. It prevents the developers from playing fast and loose with the UI, and gives them time to work out compatibility issues with the larger ecosystem. How do you place the decision to upgrade in the user's hands, while avoiding a situation where 17% of computers in the world still run Windows XP [1]? [1] http://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Desktop_and_laptop_computers http://en.wikipedia.org/wiki/Usage_share_of_operating_system...