Slashdot Mirror
A Call For Rollbacks To Previous Versions of Software
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."
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."
I like you, Stuart. You're not like everyone else, here, at Slashdot.
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.
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.
"If they send someone here, I'll arrange the usual 'accident.'" -- Alice, "Dilbert"
Never mind I found your issue in the FAQ (stupid HTML 5 bullshit). I wonder which device is the one lacking support and if there is an alternate source of the driver.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
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.
Software updates sometimes change the internal format of its database. What makes you think that a company that produces a buggy new version is capable of creating bug-free code to backport the upgraded data to the old format?
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)
I am Slashdot. Are you Slashdot as well?
Not a big deal. With 64G RAM it'll be easy to start up a VMware image of Win7Pro-x64 and give it 2 or 4 cores and 16-32G.
Multiboot is so last decade/century.
If you have good backups, you should still be able to restore. Sure, you trash whatever you might've done since the upgrade, but sometimes it's worth it.
Of course, that's not the case on the iPad -- you might've done the smart thing and backed up everything before testing a new iOS update, but once it's applied, it *will* *not* let you restore the old OS.
Build it, and they will come^Hplain.
That's because software developers are always operating under the assumption that the latest version is the greatest version, when it may not be.
No it's not. It's because engineering for backward compatibility and maintaining multiple versions is both difficult and expensive. Building, testing and maintaining multiple backward compatible versions is an expense that most app vendors probably can't afford.
Apple now lets you install old versions of Apps on iOS provided that
* You installed the old version when it was available
* The developer has not opted out of this policy in iTunes Connect
* The new version is not supported on your device
If they dropped the third requirement it might satisfy a lot of what you'd like to see.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
But you CAN'T try out the software first. You can't try it out and see if it works for you or not.
There is no back switch. There is no test drive. The user has little choice.
- Zav - Imagine a Beowulf cluster of insensitive clods...
This is a GREAT idea for my grandmother!
Oh, wait.
Even if this was something she was inclined and able to do, Apple locks it down for market share and security.
OSS is great! But it can be modified by anyone capable for good means or bad.
- Zav - Imagine a Beowulf cluster of insensitive clods...
But you CAN'T try out the software first.
It's for exactly those cases that the GP is suggesting letting other people try it out first.
systemd is Roko's Basilisk.
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.
Ah, I think I see your problem. Where did you get the idea that it was your machine?
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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.
blog
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.
Send mail here if you want to reach me.
And how is XP, by the way? I'm running 98, but it's getting a little long in the tooth. I'm thinking about upgrading to XP this April 8, when I'll consider it to be fairly well tested.
SE majors learn the how and why of release management, that's why it's relevant. IS majors learn business processes, and those tend to include release management and the importance of rollbacks.
Fortunately Windows reboots often so it will keep itself in pristine shape.
This whole we-are-always-right started with Microsoft and IE.
I think you misspelled "Bell Labs and Unix in 1969". Autocorrect is always purple monkey dishwasher.
there were articles complaining that software was never updated on mobile devices, even though the technical facility to do so was.
Now that is is being updated, complain about that, too.
If companies kept a backwards compatibility support team, the cost of new products would be higher... and you would complain about that, too, I suppose.
Quite good actually. It takes a little getting used to, but the stability improvements are enormous. I'd recommend skipping it though, 7 has reached the point that it's an improvement in almost every way, way better than the 95->98 transition, though it does have somewhat higher system requirements and there are some serious issues with backwards compatibility, especially with 16-bit software. Still, 98 mostly works without issue in most virtual machines.
Speaking of VMs, can anyone recommend a cross-platform option (Linux and Windows especially) where configured machines can be reliably moved between platforms? I'd like to be able to set up a win98 VM with all my old games - the sort of thing that will never change beyond adding new game saves, and then just install the VM software on whatever platform I have and copy the configured VM over. I've tried VirtualBox and VMware, and they both tend to have serious issues that mean I'm lucky to even get the copied VM to boot much less run stably.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Sure, I'm aware of the differences between IS, SE, and CS. But we're not talking about "developers forgot to put it in" here. Apple and others are making a deliberate decision not to include rollback for end users.
A program without bugs is either trivial or expensive to produce. In most cases, it's not worth the time and money necessary to prove the correctness of a program.
It is pitch black. You are likely to be eaten by a grue.
Devil's advocate here:
One reason that Apple may not allow downgrades is the fact that some people who downgrade might later on get stung by security issues... then blame, perhaps sue Apple for deliberately putting a downgrade mechanism that puts them back in harm's way in a backlevel iOS version.
So I've learned to never, ever update anything on my phone.
Or root it and install Titanium Backup, whenever I get a bum update I just leave a bad review and then install the backup from the previous night.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Greater acceptance in the business community? There are still plenty of corporate IT staffers who refuse to acknowledge anything made by Apple if for no other reason than the support requirements of a Microsoft environment is job security for them.
It's called "bug compatibility" and there's a valid reason for it. When you install a software package to handle some core function of your business, you build up a lot of dependencies on it. If that package has a quirk, instead of waiting for the vendor to fix it you build a way to work around that quirk. If someone later fixes that quirk, your workarounds can suddenly cause breakages.
Let's say your old accounting package has a buggy feature that automatically applies the "1% net 7" discount on an invoice but fails if you spell it in mixed case as "1% Net 7". Maybe the bookkeeper unknowingly enters them all with mixed case, but because they don't work she manually adds a 1% discount line to each invoice. When the vendor fixes the accounting package, these old discounts reappear, and the bookkeeper has to work to remove the double discounts. Worse, and more subtle, those new extra discounts might trigger a previously untested routine; perhaps the taxes on the automatic discounts are incorrectly computed on the subtotal before discounts. In this case fixing one bug triggers a new, untested feature that itself contains another bug - and the second bug is more vicious for multiple reasons. For one thing, you might check the discounts are fixed, but you don't realize this could impact taxes (which are often so complex that they're hard to figure out anyway.) So while the vendors may work with you to get the money due them; the tax collector can audit you for not collecting the right amount of tax, and create all kinds of legal problems for you.
This may seem contrived, but the scenario is common enough in the real world. Most users just have to struggle with whatever crap software they're dealt, and such workarounds have become the norm.
John
My reaction would be how shit the video driver was.
Your homework assignment for tonight is to write 5000 words comparing and contrasting the requirement that developers allow rollback of buggy releases with the requirement that developers keep their customers up-to-date with security fixes. For extra credit, discuss the consumer benefits of being able to apply individual patches a la carte versus the engineering cost of creating and maintaining a library of patches that can be applied independent of each other.
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
Shared dependencies:
Packages A and B both depend on shared library C. A critical bug is discovered in package A that requires a change to library C. Package B releases an update to stay compatible with library C. It turns out that the update to B doesn't work. There is no way to revert B to the previous version since this also requires reverting library C and package A to the version with the critical bug.
Testing:
Each old reversion point for any sort of shared library means that every package that is dependent on that library has to be fully tested with each version of the shared library. Add in multiple shared libraries and the test case tree becomes very bushy since all permutations and combinations of the shared libraries must be tested.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
When the curators of your device/app store/whatever take an X% cut of whatever moolah you spend on the application or attached subscription services, surely there's a vested interest from both parties for you not to have the ability to keep reinstalling the appallingly stone aged one that still works just fine but doesn't make them any money...? Rent seeking then becomes more profitable for both the creator and the curator, so as long as you ignore the whims of your consumers it's a win/win.
Moderation Total: -1 Troll, +3 Goat