A Call For Rollbacks To Previous Versions of Software 199
colinneagle writes "In a blog post, Andy Patrizio laments the trend — made more common in the mobile world — of companies pushing software updates ahead without the ability to roll back to previous versions in the event that the user simply doesn't like it. iOS 7.1, for example, has reportedly been killing some users' battery power, and users of the iTunes library app TuneUp will remember how the much-maligned version 3.0 effectively killed the company behind it (new owners have since taken over TuneUp and plans to bring back the older version).
The ability to undo a problematic install should be mandatory, but in too many instances it is not. That's because software developers are always operating under the assumption that the latest version is the greatest version, when it may not be. This is especially true in the smartphone and tablet world. There is no rollback to be had for anything in the iOS and Android worlds. Until the day comes when software developers start releasing perfectly functioning, error-free code, we need the ability to go backwards with all software."
The ability to undo a problematic install should be mandatory, but in too many instances it is not. That's because software developers are always operating under the assumption that the latest version is the greatest version, when it may not be. This is especially true in the smartphone and tablet world. There is no rollback to be had for anything in the iOS and Android worlds. Until the day comes when software developers start releasing perfectly functioning, error-free code, we need the ability to go backwards with all software."
The ones I really hate... (Score:4, Insightful)
Are the updates where the hardware requirements have changed so much that you effectively have to buy new hardware. Obviously, not an issue for phones, but annoying as hell on PCs.
Or the company that comes out with an (non-free) upgrade ~every~ year, necessary or not, and immediately stops supporting the previous version. "Yeah, we know about that rare bug. It's fixed in the latest version, which will only cost you $150k, across your user base, to upgrade to."
Which is why I recommend running 1 version behind. (Score:4, Insightful)
You can avoid the pain of new releases, at least in most cases, by simply deferring the upgrade until a period of time has passed whereby the new release will be vetted by those eager to try it.
Devs don't want to maintain old versions (Score:5, Insightful)
Developers don't like having a lot of different versions of their software out in the world because it means they have to maintain those versions. Adding some sort of default rollback ability implies that devs will have to continue to support those old versions. That's not going to be very popular.
On the other hand (Score:4, Insightful)
Rollback functionality is also not guaranteed to be perfectly functioning, error-free code, and there's no guarantee that reverting to the previous software version will also revert the user experience to its previous status.
What about data changes? (Score:5, Insightful)
Re:New Mac Pro sans Windows 7 (Score:4, Insightful)
It's because windows 7 cant cope with the modern hardware.
Which is why I run Windows 7 under a VM on Mavericks (well actually multiple VM's with different versions of W7)
Too much server integration to go back (Score:3, Insightful)
The problem with making the argument that you should be able to revert to older versions of software is that software is more and more getting at least some functionality from a server component. Sure that server has to allow migration from an older version to the next, but the truth is you just can't maintain server versions for every client forever.
This isn't even a mobile only issue anymore as lots of desktop software these days has server interaction. It's a consequence of moving to a world with more pervasive networking.
Re:Downgrading is a horrible idea. (Score:5, Insightful)
Sure, occasionally it would be nice to go back.
Or more than occasionally, if I've forgotten to turn of the abomination that is automatic updates.
The upgrade might be required to work with changes to the back-end server for example.
Which is yet another point in the lengthy list of reasons to avoid anything that depends on the cloud or proprietary third party servers to function.
Ultimately, the best solution is for the users to quit being such whiney bitches.
Ultimately, the best solution is for developers who can't bring themselves to actually take customer needs and desires seriously (or at least to stop insulting them) to get out of the business that they obviously loathe.
Re:Shades of WinAmp 3 ? (Score:5, Insightful)
Ah, I think I see your problem. Where did you get the idea that it was your machine?
Re:Shades of WinAmp 3 ? (Score:5, Insightful)
I really don't like when companies turn my app from a standalone product to one requiring a subscription to access new features. BranchFire did it with "PDF Annotate" and Abvio has done it with "Cyclemeter".
Part of the reason I purchased "PDF Annotate" and "Cyclemeter" ($25 and $5, respectively) is they didn't phone home or require a subscription that was looking for an excuse to go belly up.
My guess is once new user growth slows, the companies consider monetizing their current user base (aka "seeking rent"). So, in the next upgrade they introduce subscription services.
I'm sorry, but I'm not interested. At all.
Users should have the ability to roll back any upgrade, including OS upgrades.
Harder than it sounds (Score:5, Insightful)
I've been in charge of update deployment and strategy for several companies now. There's a few issues that come into play when deciding whether an update can be reverted or not. For a trivial app that doesn't maintain much data there's no real issue. Anything that does maintain real data, you must determine whether the database schema change between version A and version B is backwards compatible so that you can roll from B back to A. If the database schema change is incompatible, then you can't roll back. Same thing with on-disk data formats in general. I have Fedora 20 installed on one of my systems. If I wanted to roll back to the previous Centos 6 I couldn't, because the XFS file system format changed between 2.6.32 and 3.12. Centos won't mount Fedora 20 XFS filesystems.
Then there's binary compatibility issues. One release of one employer's software was based on Fedora 7 with a lot of modifications (different kernel, various applications updated, etc.). The next major release was, due to a gigantic change in hardware architecture for their newest systems, based on Fedora 13, including a major version update to Postgres for the database. The upgrade process runs out of a special imaging initrd and consists of save off the database with pg_dump to a couple of data drives, wipe out the base OS, plop on the new base OS, install the new application layer on top of the base OS, and restore the database with pg_restore. The pg_dump and pg_restore are necessary because the binary format of Postgres databases changed between the two different versions of Postgres. Downgrading in this case is impossible because the older version didn't know how to do pg_dump and pg_restore, since its previous releases had used the same antique version of Postgres (a version so old it wouldn't even compile under Fedora 13).
Finally, there's the question of whether an update scheme even has provisions for forcing arbitrary versions. The ones I've designed did, mostly because they were for very large data storage appliances where you didn't want anything updating automatically because scheduling a service outage for the update is a Big Deal for big data storage systems and where you needed the ability to roll back to the previous version if the update happened half-baked (if, say, the power supplies both blew out halfway through the update and left it only halfway on the disk). So you had to manually select which version you wished to update to, based on a list of what was compatible with your hardware and current installed version. But it appears to me that Apple has no such ability within their App Store interface. They make only the latest version available, period, even if it isn't compatible with your older iDevice.
So: Being able to roll back to the older version of the software is a lofty goal. But sometimes it just isn't feasible. On our web application once the database format has been updated to a new incompatible schema and new data is flowing in, there's no going back -- even though we saved off a copy of the old database before doing the database schema change, going back would discard all the new data that's flowed in since. So we cross our fingers, run it in parallel with a clone of the old system's data stream for a while to assure ourselves it won't blow up, and test the bleep out of it before cutting it over as the active version. Because once it's been in service for over a couple of hours there's no going back -- people may tolerate losing a few updates, but not days worth.
That said, when I had my Europa Universalis IV save games wiped out by an update to EUIV that Steam auto-updated without my consent or knowledge, I certainly was peeved! I should have at least been given the opportunity to *not* update, which even Apple gives you. That would have allowed me to spend a couple of days researching the update and waiting for people's feedback on whether it was worthy or not. Instead... sigh. So it goes.
Re:The ones I really hate... (Score:5, Insightful)
You think every year is bad, we had a vendor once who went to an 'agile' release cycle and started pumping out releases every 2-4 weeks, and then would say they couldn't support you because you were out of date.
Our production deployment cycle is longer than 2-4 weeks, and we eventually had to tell them that if they expect to be making grown up software for production environments, they'd need to support any given release for no less than six months to a year, or we'd terminate the contract. It took some yelling for them to understand that real production environments can't be updated every time a developer bloody well recompiles.
I updated an app on my Android phone from the Play store recently, and *after* I updated it it started telling me it was only Beta software. Why the hell didn't you tell me is was a steaming turd in the bloody app store? Because I have no interest in a beta version of your damned software.
Re:Devs don't want to maintain old versions (Score:4, Insightful)
Developers of course would prefer to work on 'sexy' things like new features; maintaining older versions and backporting security updates and bugfixes is decidedly 'unsexy' in comparison.
It's not just "unsexy," it's downright annoying to try to dig through an old codebase written poorly by people who have since left the company/community and has since been replaced in newer versions. It'd be one thing if that was free, but trying to maintain that abandoned code requires real work, often far more work than in your current codebase. The more effort you have to expend to maintain the old code, the more complicated and bug-ridden complimentary servers (like online servers and database servers) have to become in order to interact with multiple versions of the app, and the more resources are siphoned away from working on the future. Eventually your project will grind to a halt the more old versions you have to support so obviously you have to draw a line somewhere.
Re:Devs don't want to maintain old versions (Score:5, Insightful)
who asked for maintenance? I just want to be able to reinstall the same version I was already running before, if to do so I have to click a 'this is unsupported, you are on your own' checkbox then whatever, I just want to:
- if I have an old device and I wipe it, I want to be able to reinstall the applications I ALREADY HAD ON IT even if new versions are available (which would not run on it)
- if a developer releases a bad update (significant changes in functionality, crash bugs in my scenario, redesign, whatever), I want to be able to downgrade to the previous version I ALREADY HAD
developers would totally be free to say 'if you want this issue fixed you need to upgrade to version x.y.z', that's fine with me, but as things stand now the state of walled garden app markets is not very good: if in my job I told my customers that they have to force upgrade to every release (major OR minor) I put out and they won't be able to downgrade after doing so I would (rightly) go out of business very quickly.
Your homework assignement for tonight (Score:4, Insightful)