If you have to do all that, it costs a lot more to develop updates. I think most developers mean well but just can't afford to do it all.
For example:
> should be incremental and security or bug fixes only
That means maintaining multiple releases of the app, and porting fixes between those versions, while also maintaining data migration logic when fixes affect data formats. I've maintained an enterprise software suite before where we did it like that, and it added a double digit percentage to the cost of development. You also get drawn into a discussion of what exactly constitutes a fix. Some users consider a missing feature a bug, sometimes they're right.
> should never update a user interface without allowing the previous one to be used as the default
I hope you've maintained a very clean separation between view an controller layers, because otherwise you'll have duplicate business logic and tons of bugs. Again, been there, done that, was not a happy camper.
> must allow a revert to the previous situation
So, maintaining and testing data migration algorithms in both directions then?
> should never change the format of data already stored on the system
Multiple independent read and write paths? How many combinations of UI and data logic do you get? A combinatorial explosion can cause this to become effectively untestable.
Granted, some developers are bad, and abuse automatic updates. I swore off Oracle Java after a security update installed malware on my system (called Norton Antivirus). But most developers are not like that. They mean well, they're doing the best they can given their limited resources.
That's the point. If updates are expensive, you'd think twice about pushing one out every week for no good reason.
As far as file formats go, how often do you need to change these, anyway? I'm fascinated with most of the mainstream file formats (except mp3, mp3 sucks) — they're built with extreme extensibility in mind, and you have to try really hard to make something incompatible with the rest of the world. So, then, what stops you from designing your own file formats to be extensible? You add a new feature, you add a new section to your file. The user downgrades, and the old version skips over that section because it doesn't know about it. It's easy.
And besides, I've seen a lot of software that's able to save files that are 100% compatible with older versions of itself if that's what the user asks for. Microsoft Office is one example.
It doesn't mean any of those things. It just means not making the updates automatic. Make your auto-update just say "hey your version is no longer getting updates, you can get the new version at this link"
I do that kind of maintenance. Sometimes it's reverse migration code. Because CD doesn't fly. Maybe people don't know it doesn't fly and still push it, or they know it doesn't fly and still push it. And there's no asymmetry between user and developer, developers are users too and experience all this first hand from the user side.
For example:
> should be incremental and security or bug fixes only
That means maintaining multiple releases of the app, and porting fixes between those versions, while also maintaining data migration logic when fixes affect data formats. I've maintained an enterprise software suite before where we did it like that, and it added a double digit percentage to the cost of development. You also get drawn into a discussion of what exactly constitutes a fix. Some users consider a missing feature a bug, sometimes they're right.
> should never update a user interface without allowing the previous one to be used as the default
I hope you've maintained a very clean separation between view an controller layers, because otherwise you'll have duplicate business logic and tons of bugs. Again, been there, done that, was not a happy camper.
> must allow a revert to the previous situation
So, maintaining and testing data migration algorithms in both directions then?
> should never change the format of data already stored on the system
Multiple independent read and write paths? How many combinations of UI and data logic do you get? A combinatorial explosion can cause this to become effectively untestable.
Granted, some developers are bad, and abuse automatic updates. I swore off Oracle Java after a security update installed malware on my system (called Norton Antivirus). But most developers are not like that. They mean well, they're doing the best they can given their limited resources.